Well, let me see what you want to do with your 1000 spheres
problem. Every frame you want to draw a certain number of
spheres, max. no. = 1000. Your Java 3D approach, which
you don't seem to favor, is to pre-allocate and make live all the
1000 spheres and at every frame determine which of these
you need to blank out - your "visible-state-management" policy.
You would, however, prefer a procedure where you have somehow
determined the collection of spheres that need to be rendered
in the current frame and simply would want to do just that.
Is my understanding of your problem correct ?
I think a solution for your problem would be to use a
GeometryArray with:
(a) Coordinate/Color/etc read/write (OR) ByRef capability,
and Count read/write capability
(b) coordinate and attribute arrays long enough to
accomodate all your 1000 spheres
(c) fill up these arrays with the new collection
of sphere data for the current frame
(d) set the valid vertex count appropriately
Never had an occasion to play with setValidVertexCount()
feature though !!!
A second approach would be to set the allow geometry write
capability on the Shape3D and set a new GeometryArray
with exactly the new sphere collection every frame. This
would be less appealing in terms of memory usage, however.
Vaidya
>On Thu, 26 Jun 2003 18:33:22 +0200, MisterXen <[EMAIL PROTECTED]> wrote:
>Hi Justin,
>
>>> huge overhead, since I have to manage "visible"-state for each sphere
>>> primitive and management of the states is a real pain! And building a
>>> complete scene tree for each frame is impossible! In OpenGL I can do per
>>> frame (immediate mode) what I want to draw! Any ideas how I could do
>>> that
>>> with Java3D??? I think no!
>>
>> Sure. Use the RenderingAttribute class and call setVisible(). Only call
>> it on objects that have changed state this frame.
>Thats exactly what I did :))) It's not an apropiate solution for the
>problem described above, since I (still) have to manage the visible-states!
>
>> So far from your comments, you are appearing to be extremely ignorant
>> about what scene graphs are and how they function in general.
>Ignorant isn't the right word. As I wrote in the beginning of the thread,
>the scenegraph implementation used in Java3D is not complete in my opinion.
>And I´m sure to know the features and benefits of a scenegraph in general.
>I said, that most (and that means not all) features the Java3D scenegraph
>provides are 1:1 mappings to OpenGL. Java3D provides just too less
>scenegraph features, which would make it worth using. (see below)
>
>I tried not to make any statements like: Java3D can't to this and that. But
>concerning the buffers I wasn't right, thats true.
>
>> I suggest
>> you do a heap more reading first before you claim anything more about
>> what j3D can and cannot do. Other very salient points you seem to have
>> completely ignored are things like culling, multipipe rendering, state
>> sorting inbuilt picking and many many more features that would take you
>> hundreds of hours to implement if you were to start from scratch.
>Concerning your last sentence: If you think, that is true, I have to
>disappoint you. It took me ~20hours to adapt my application to use an
>OpenGL binding instead of Java3D. And this concerns features like picking &
>selection, depth-sorted transparency and two different kinds of stereo view
>(field-sequential and column-interleaved), which I had to implement myself.
>(and which couldn't be achieved because of the missing StencilBuffer
>functions in Java3D) So maybe I´m not able to use Java3D properly or Java3D
>just isn't so "well-designed" as you claim! The adaption was so easy and
>quick because Java3D is a somewhat 1:1 mapping to OpenGL.
>
>Apart from that, how can you explain, that my application runs a factor 2
>faster using an OpenGL-binding, if Java3D is such a well optimizing
>scenegraph system???
>
>Additionally it took me 10hours to implement picking and selection with
>Java3D (first bounding boxes to make estimations which objects the click
>concerns, then detailed intersection tests). On the other hand it took me
>10hours to make the same selection routines in OpenGL which are faster by a
>factor of 10. So Java3D is such a well optimized system! =:)
>
>
>Best regards
>
>MisterXen
>
> ==========================================================================
>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".
