← Users | Developers → | |||||||||||||||||||
Intro | News | view3dscene | The Castle | All Programs | Forum | Donate | Engine | VRML/X3D | Blender |
VRML 1.0 (old) extensionsContents: 1. Lights can be globalAll light source nodes have global field. The default value of it is FALSE, and it means to use standard VRML 1.0 light scope rules (light affects everything following, and is delimited by Separator). You can change it to global = TRUE, and then the standard X3D global light behavior will be used: light will affect everything, regardless of light node placement in node graph. For developers: this also indicates that light shines on other 3D objects, outside of this scene, if you use TCastleSceneManager.GlobalLights := true;. Very useful to make your creatures, items and such lit by the level lights. 2. Lights have attenuationLights that have a position, i.e. PointLight and SpotLight nodes, have the field attenuation. The meaning of this field is exactly the same as in VRML 97. I allow this for VRML 1.0 because this is really useful, and because the default value of this field (1,0,0) assures that standard VRML 1.0 files are interpreted correctly.3. Lights have ambientIntensityAll lights have ambientIntensity field, also defined exactly like in VRML 97. However, when reading VRML 1.0 files, we treat default value of ambientIntensity as -1 (while VRML 97 specification gives 0). And when rendering, we treat lights with ambientIntensity < 0 specially: we treat them like ambientIntensity = intensity. This way:
4. Parts of Inventor in VRMLSome Inventor-specific things are allowed:
These things allow me to handle many Inventor 1.0 files. They also allow me to handle many broken VRML 1.0 files that sometimes falsely claim that they are VRML 1.0 while in fact they use some Inventor-specific features. For completely unrecognized nodes, our engine can always omit them (even without any VRML >= 2.0 (protos) or VRML 1.0 ("fields", "isA") extensibility features), so most Inventor files can be at least partially handled and displayed. 5. Multi root nodeVRML 1.0 file may have any number of root nodes (VRML 1.0 spec requires that there is exactly one root node). I implemented this because
6. Field separate for WWWInline nodeI'm adding new field:WWWInline { ... all normal WWWInline fields ... SFBool [in,out] separate TRUE } To explain this field, let's create an example. Assume you have file 1.wrl with following contents: #VRML V1.0 ascii Material { diffuseColor 1 0 0 }And a file 2.wrl with following contents: #VRML V1.0 ascii Group { WWWInline { name "1.wrl" } Cube { } } Question: what material is used by the cube ? The red material (defined in 1.wrl) or the default material ? In other words, do the state changes inside 1.wrl "leak outside" of WWWInline node ? The answer (stated by VRML specification, and followed by our programs when separate is TRUE (the default)) is that the cube uses the default material. Not the red material. In other words, state changes do not "leak" outside. This is definitely a sensible behavior. This is safer for the author of VRML files (you're not so "vulnerable" to changes done in included files). And it allows to delay loading of inlined file until it's really needed (e.g. is potentially visible). Effectively, this means that WWWInline behaves a little like a Separator node. File 2.wrl is equivalent to #VRML V1.0 ascii Group { Separator { Material { diffuseColor 1 0 0 } } Cube { } } On the other hand, when you set field separate to FALSE, the cube will be red. Every state change done inside inlined file will affect the things defined after WWWInline node. Effectively, this means that WWWInline behaves a little like a Group node. Two files below are equivalent: #VRML V1.0 ascii Group { WWWInline { name "1.wrl" separare FALSE } Cube { } } #VRML V1.0 ascii Group { Group { Material { diffuseColor 1 0 0 } } Cube { } } Generally, setting field separate to FALSE is a little dangerous (because you have to be careful what you include), but it also allows you to do various tricks. Test VRML file: see our VRML/X3D demo models, file vrml_1/castle_extensions/inline_not_separate.wrl. 7. Field parts in Cone and Cylinder nodes may have value NONEThis way every possible value is allowed for parts field. This is comfortable for operating on these nodes, especially from programs — there is no special "forbidden" value. |