[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [www-vrml] [xVRML] new screen snapshots and the future
Stefan Westphal wrote:
Hi,
mistakes may happen, but my point was different:
in vrml-spec most fields are exposedFields that is nice, but
ca 40% are IN's, OUT's or only 'fields'.
That normally makes no problem when you stay in one file, but
if you need to use protos and want to change those fields from outside
proto you need some script workarounds to do.
Also I sometimes wondered why some fields need to be IN's or Out's,
where exposed's would ease the vrml. (so only it might have eased the
parser production)
usually the reason for inputOnly or outputOnly or initializeOnly is one
of the top three reasons browser builders give: performance, performance
and performance. they don't like to keep around any heavyweight data
structures that might get optimized into something else underneath.
next reason is that the inputOnly (eventIn) and outputOnly (eventOut)
are usually only there to carefully expose input or output functionality
when less-than-complete exposure is desirable.
that said, i agree that it is a major major pain to deal with lack of
exposedField in VRML97 Script fields. you can find lots of workarounds
to this limitation in the X3D examples. good news, however:
accessType inputOutput (formerly exposedField) _is allowed_ in X3D
Script fields.
as a result, i don't know of any node/field combinations that can't be
properly dealt with due to lack of inputOutput (exposedField) access.
counterexamples welcome.
so, for those advanced prototype/script authors who have hit their heads
on this low doorway before, this is an excellent motivation to upgrade
to X3D from VRML97.
Second (main) VRMLprob was allways the createVrmlFromString depending
pre USEd nodes and pre PROTO definated nodes.
I hope this will be much more smarter in future.
I think it is the same. Usually the way to deal with this problem is
to rethink the design of the constructed scene graph, if possible.
Third I think there was no way to search on 'DEF' names of script-generated
children, especial the array possibilities of vrml where hard to do. The
def's I might be false, but I was not be able to do.
Agreed and IMO unfortunate that DEF values are not directly accessible at
runtime. Though, if predeclared as part of IMPORT and EXPORT statements,
they should be accessible. Not sure, haven't tried.
This is candidate functionality that might be proposed in this years'
X3D Amendment 2, if someone can come up with changes to Scene Access
Interface (SAI) that implementers can agree with.
Forth inlines had not in all vrmlbrowsers the loaded children able to
read from a script.
Not sure what you mean here, please advise.
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br work +1.831.656.2149
MOVES Institute, Monterey CA 93943-5000 USA fax +1.831.656.7599
Virtual worlds/underwater robots/X3D/XMSF http://web.nps.navy.mil/~brutzman
-------------------------------------------------------------------------
for list subscription/unsubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html