Hi Artur,

Some of the forms of extensibility that we are considering for 1.4 allow
for this kind of operation.  Specifically, geometry extensibility follows
your InvisibleNode approach, although there are a few other data items
needed by the system.

When you start talking about making it generic, things get out of hand
pretty quickly.  State sorting, for instance, pretty much goes out the
window.  There is no way to know exactly what each node will do, so you
lose a whole bunch of optimization possibilities.  So, we are looking to
add specific points of extensibility that preserve the optimizations we
can perform on "core" nodes.

There have been attepts at fully extensible scene graphs over time, and
all have had a very hard time meeting the performance requirements.

Doug Twilleager
Java 3D Team
Sun Microsystems


>
>There was some hint about possible implementation of WakeupWhenVisible
>for 1.4. Then there was a hint about abstract rendering interface. Then
>I have read some doc of opengl OpenSceneGraph... Probably my idea is
>quite obvious for most of you, but I would like to know if it is
>possible, if not, why, if yes, is there a chance of getting something
>like this in 1.4...
>
>Basic idea is to create callback which will be called when given bounds
>in space is going to be rendered. This is a bit different from possible
>WakeupWhenVisible behavior - because it would be called in render
>thread, in the middle of drawing data to screen.
>
>This could be done in 3 basic ways. Either create special kind of
>InvisibleNode, which would have special method to be overridden which
>would be called when it is turn to for InvisibleNode to be 'drawn'. More
>generic would be add such method to every Node - so it would be also
>possible to add custom functionality to Shape3D, without adding extra
>nodes to graph. Most elegant IMHO, would be to add something like
>userData, only with object being instance of some kind of interface.
>This way, no subclassing of core nodes would be needed and same render
>callback could be used for many types of nodes. If they could be linked,
>like listeners on awt components...
>
>A lot of things could be made almost obsolete by such addition... Think
>about LOD - now it requires separate behavior and Switch node. With
>callback, it would be just simple check of distance(view,this) and
>drawing given shape. Yes, we already have working LOD, but fact that
>something custom, working in similar way, could be implemented by hand
>gives some proof of extensibility of system... Same could be probably
>done for SharedGroup/Link. Maybe even these classes could be implemented
>in terms of this functionality - and migrate from 'magic-core-class' to
>'example-helper-class'.
>
>It would be great if geometry could be updated at this step. A lot of
>stuff could be drawn here without help of automatic triangle sorting and
>OrderedGroup. You could play with z-buffer and transparency on the fly.
>
>Generally, it would be kind of immediate-inside-retained mode hook -
>taking advantage of existing occluding, maybe also some state sorting ?
>
>A lot of this stuff can be achieved today by smart combination of
>behaviors, geometry updaters, intermediate mode, ordered groups etc. But
>I think that above solution would provide cleanest solution to a lot of
>problems. Basic question is if it could be made in well performing way
>with current java3d render structure ?
>
>Artur
>
>===========================================================================
>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".

Reply via email to