VRML - strange bug with strange work-round in blaxxun contact

Author

strange bug with strange work-round in blaxxun contact

simon

2005-11-09, 7:01 pm

after having been bitten again by this bug in blaxxun contact, esp.in
complex worlds where its nice fast engine is particularly useful, i've
spent some time pinning it down and produced the simplest example i can
think of that shows it, also found a work-round.

code below works,( produces 3 different flat shapes ) but only does so
when the dummy def is included.

#VRML V2.0 utf8
PROTO IndexedFaceSetShapeSubClass [
field MFVec3f def []
]{
Shape {
appearance Appearance { material Material { }
}
geometry DEF main IndexedFaceSet {
coordIndex [0,1,2,3]
coord DEF dummyDef Coordinate { point [] } }
}

DEF build Script {
field SFNode faceSet USE main
field MFVec3f points IS def

## comment the dummy line below and blaxxun contact uses the
points
from the last use for all nodes made from this proto!!
field SFNode faceSet1 USE dummyDef

directOutput TRUE
url ["java script:
function initialize(){
faceSet.coord.point=points ;
}
"]

}}

## oblong
IndexedFaceSetShapeSubClass {def [0 0 0,2 0 0,2 .5 0,0 .5 0,]}

Transform {translation -2.5 0 0
children [
## square
IndexedFaceSetShapeSubClass {def [0 0 0,1 0 0,1 1 0,0 1
0,]}
]

}

Transform {translation 2.5 0 0
children [
## oblong
IndexedFaceSetShapeSubClass {def [0 0 0,.5 0 0,.5 2 0,0
2 0,]}
]
}

fabricator

2005-11-10, 3:33 am

you can remove the Script if you replace this line:

coord DEF dummyDef Coordinate { point [] } }

with:
coord Coordinate { point IS def} }

The exact reason for this problem is due to the way contact was
optomized to reduce CPU load and memory usage for multiple identical
PROTO instances.

There are two solutions to prevent the problem you found, the first
involves a Script node with directOutput TRUE which creates some part
of the geometry, which is what did. The second way is the map some
field from the Shape itself to the PROTO headers.

Paul Aslin
http://www.vrmlworlds.com/

simon

2005-11-10, 7:00 pm

thank for this other work-round,

but i think you now also have to add an unused field ( def ) in your
proto, and i think this would reduce the readability of the code more
than the way i had it.

although, i suppose, these dummy fields can be hidden when the proto is
used externally,

still, i don't really see any excuse for this bug, couldn't something
like a parser level effectively add these when required before any
lower level gets its hands on it.