Hi Justin, Thanks for the more detailed explanation. I do see your dilemma. What about adding a MINIMISE_SHARED_GROUPS flag that does not share any node that is not USEd? i guess that would require a multi-pass parser, eh? Hm. What about a NO_SHARED_GROUPS flag with the caveat that you can't use EAI, Scripting, USE or ROUTES? Selfishly it would work for me. :-)
Thanks for the suggestion of the alternate getLocalToVworld method. I will look into it when I have time but for the meantime I will have to finish developping the rest of my app. josh >>> [EMAIL PROTECTED] 01/11/02 04:38PM >>> Josh Richmond wrote: > I definitely need to use getLocalToVworld on Def'd nodes. I use the DEF > tags to extract references to Transform nodes in my code. Ok, I understand your problem, and we don't have a short-term solution. It is a small part of a bigger problem that we have anyway which we do need to sort out one day. Alan and I are having a chat about this right now anyway. Here's a long-winded technical reason why it is not so easy to "fix". 99% of it we can blame on the VRML spec :) In VRML, the scene graph is a wonderfully flexible thing. There are all sorts of things that you can do with it. By itself, that doesn't pose much of a problem to implementing it with Java3D. Where we start coming un-stuck is when you start combining the scene graph with scripting, and potentially with external access. Scripts can do all sorts of nasty things. They can grab bits of the scene and change the structure around whenever they want. As we parse through a file, we have no idea about the intentions of the end user. Did that DEF get put in there as just a marker. Was it used for routing or was the user going to make use of it in a Script or Proto or shared instance with USE. Where it might be possible to eliminate the sharedgroup sometimes, we can't say for certain really whether we can. Think of loading a world up where the EAI is in action. That object that we thought was not shared (it was never USEd) now gets grabbed through Browser.getNode() and added as child to another node too. In the loader case, we could make a few more assumptions as we can (probably) safely assume that the EAI is non-existent, but we still have scripts to deal with. One option that Alan and I are discussing is adding a bunch of extra flags, or maybe trying to infer stuff from the standard flags a bit more. But the scripting stuff still comes back to bite us. The sad fact is that for almost every other file format, Sun's loader interface works a treat, for VRML it is a horrible failure. There are just so many assumptions made with the Loader interface that are in direct conflict with the VRML assumptions that we are struggling to get it to work at all. Several times I have seriously considered dropping the loader stuff completely, but people still want it. Unless all you ever do is load coloured geometry with no textures, the loader system is just completely inappropriate for VRML files. > I'm not sure > how I can get around this from outside the loader, but if you have any > ideas I'd appreciate them. You get the exception because you have the wrong form of getLocalToVworld(). The other form you give it a SceneGraphPath which contains the list of SharedGroups from the root of the scenegraph. If you knew specifics about your scene graph structure, you could do something like create an explicit path to use to fetch the transform. -- Justin Couch http://www.vlc.com.au/~justin/ Freelance Java Consultant http://www.yumetech.com/ Author, Java 3D FAQ Maintainer http://www.j3d.org/ ------------------------------------------------------------------- "Humanism is dead. Animals think, feel; so do machines now. Neither man nor woman is the measure of all things. Every organism processes data according to its domain, its environment; you, with all your brains, would be useless in a mouse's universe..." - Greg Bear, Slant ------------------------------------------------------------------- =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". ==========================================================================To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
