3D Models

3D model library can be considered as most complicated part. We have several options how to create 3D models for the model library:

  • Use 3D modeller. There are some around. With 3D modeller you do not need to understand VRML file format and VRML syntax. But on the other side the VRML files produced by 3D modellers are usually very big and inefficient. For example QFP64 model found in model library of another well-known free CAD software has about 220kB in size. Additionally you cannot benefit from variable substitution and conditional processing of 3D models, which is implemented in VRML export filter
  • Create the model by hand. It is good method,  you can use all features of VRML specification, including DEF/USE or PROTO. You can also use variable substitution and conditional processing. But this method is very slow and boring.
  • Write scripts to generate parametrized models for you. Such scripts can be used to create models on-fly, they can be used to create model prototypes which can be manually modified afterwards to get required new model. You can also fully benefit from variable substitution and conditional processing. Just for comparison – QFP64 model created by our script has 6kB only. Scripting is not easiest way, but it is the most effective way – with one simple and smart script you can cover the the whole family of components.

Design rules

The 3D models have to follow several simple rules:

  • All dimensions are in millimeters
  • The coordinate system is the native VRML coordinate system: X axis heads to the right, Y axis heads up and Z axis heads to you.
  • The componet lies on XY plane, with top on positive Z side
  • The Z axis passes through center mark of footprint
  • The Z=0 plane is aligned with top of copper plane on PCB
  • It must be possible to enclose whole model inside grouping constructs like Transform or Group
  • All definitions (PROTO or DEF/USE) should use instance number placeholder as part of the name (we will discuss instance numbers later)

Instance number

Because all models are embedded into output file we have to avoid any kind of duplicities in named entities. It applies for  DEF/USE clauses or PROTO declarations. These duplicities are forbidden by definition and VRML viewers can process these duplicities inconsistently.

The  solution is very simple – you should use unique instance identifier. Instance identifier is sequential number of model – each model gets it’s own unique sequence number. If the same model is included several times, each instance gets it’s own instance number.

The instance number can be embedded into the model using instance number placeholder – @@@.

When the model is embedded into output file, each occurence of placeholder is replaced by instance number. So if we use “DEF name@@@” and “USE name@@@” constructs, they will expand to “DEF name1” and “USE name1” in output file (for first model).

Always separate @@@ placeholder from digits in the name by at least one non-digit character. Otherwise, for example,  the expanded name name1@@@ of 3rd element (name13)  will collide with expanded name name@@@ of 13th element.

Variable substitution and conditional output

The 3D model can be modified on fly using variables and conditional processing.

Variable is identified by their name, surrounded by @. When model is embedded into output file, the variable is replaced by it’s respective value. Value of  variable is specified in the project map file or component map file. Map files and their processing is described in VRML export filter.

If the variable is undefined, it’s name (including surrounding @) remains unchanged in the output file.

The variables in the VRML model usually break the syntactical correctness of the model and such model containing variables cannot be displayed by VRML viewer. This behavior significantly complicate the  model development and debugging.

As solution,  conditional lines were implemented. Conditional line consist of three parts:

  • default value, which is syntactically correct VRML code
  • separator #@@
  • VRML code with variables

The separator is in fact start of the comment. Therefore the VRML code in unprocessed file is syntactically correct and model can be displayed in VRML viewer. Here is typical conditional line:

material Material {	diffuseColor
	0.9 0.9 0.9 shininess 0.2 #@@ @LEAD_COLOR@
}

In unprocessed model  the default value (left part) is used and rest of line is ignored as comment. When the model is processed by export filter, it checks if all variables used in the right part are defined. If all variables are defined then the left part (including separator) is removed and variables in right part are replaced by their values. If any of variables is undefined, the default value is used and right part (including separator) is removed.

The conditional lines are a bit quirky, but they are the most simple way to include variables into VRML file and retain the syntactical correctness of the file at the same time.

Second conditional construct is conditional block. The conditional block is piece of VRML code, surrounded by special comment lines:

#{{VARIABLE
...VRML code...
#}}

The block is written into output files when variable named in opening block is defined (the value is not important). Note  that there is no @ surrounding the variable name.

The variables in the VRML code inside the conditional block are expanded usual way.

Model scripts

All models can be generated by scripts on-fly. The same rules apply for the these models. The scripts can be used two different ways:

  • use the script as the value of variables model, alt_model, overlay or alt_overlay. This model will be called during export and model is created on fly. You do not need to maintain any library of component models.  On the other side the export filter has to run several hundreds or thousands of scripts (e.g. for axial resistor four scripts has to be ran: one for model, three for stripe colors)
  • run the script manually and save it into component library.  You can also modify the final output file (for example you can create pin header with missing pin  or you can produce DIP with missing pins).

To automate library creation we use shell scripts to create footprints and their corresponding map files. (These scripts are available in Download area):

$FPPATH/fp-chip.pl -r RESC_2012_60H__Yageo_0805_Series 0.95 1.4 0.95 0.2 1.1 > $FPLIB/PASSIVE/RESC_2012_60H__Yageo_0805_Series.fp
cat > $FPLIB/PASSIVE/RESC_2012_60H__Yageo_0805_Series.m3d <<EOF
model: @chip-r.pl 2 0.35 1.25 0.5
LABEL: @val-rs3.pl
EOF

These scripts can be modified to generate static models easily:

$FPPATH/fp-chip.pl -r RESC_2012_60H__Yageo_0805_Series 0.95 1.4 0.95 0.2 1.1 > $FPLIB/PASSIVE/RESC_2012_60H__Yageo_0805_Series.fp
$VSPATH/chip-r.pl 2 0.35 1.25 0.5 > $VLIB/PASSIVE/RESC_2012_60H__Yageo_0805_Series.wrl
cat > $FPLIB/PASSIVE/RESC_2012_60H__Yageo_0805_Series.m3d <<EOF
model: PASSIVE/RESC_2012_60H__Yageo_0805_Series.wrl
LABEL: @val-rs3.pl
EOF
Print Friendly