Check the level of Java 3D installed on OSX.  I believe that method was introduced a while ago (J3D 1.3 or 1.4?).

Mike

Check out this article: http://jdj.sys-con.com/read/48544.htm

Perhaps you are looking for something like this: http://photos.sys-con.com/story/res/48544/fig4.jpg

or this: http://photos.sys-con.com/story/res/48544/fig10.jpg

Note that transparency and animation can really affect framerate.

Mike

Layered imposter rendering is used.  No scattering or self shadowing is done.  Procedural texturing techniques are used to create the variations in the density and color to create the cloud depth.  The CloudPuff class allows for variations in the procedure texturing to create different types of clouds.

Did that answer your question?

Mike

Are you using only one white directional light?  If so, have you considered using the cloud image to create a normal map and using a DOT3 combine mode to get the shading for free in the GPU?

Mike

Great to hear. 

I believe Java3D has a few problems (namely geometry locking: https://java3d.dev.java.net/issues/show_bug.cgi?id=39) with rendering if the updates are done in a separate thread like that.  If all the thread does is sleep, compute the next point and add it, I would suggest moving that function to a behavior.

I have run out of ideas.  This problem is very strange.  The fact that the geometry data is the same between the working and failing scenarios leads me to think it is rendering related.  I think the last idea I have is to ensure you have the latest drivers for your video card.

BTW, The LineStripArray uses vertices like this: V1-------V2-------V3 which implicity defines two segments: V1 to V2 and V2 to V3.  The V2 instance is shared enabling the creation of a long sequence of connected segments.  The strips define where a new series of connected vertices starts.

Mike

I don't have the code that uses the ElementTrail, but I assume that there is a behavior that wakes up (every frame or every x milliseconds) calculates the next point for the attractor and then uses addPoint() on the ElementTrail.  Is that right?

It looks like when the by reference data reaches capacity in addPoint(), a new array is allocated with twice the old capacity, the old data is copied and the new array is intended to be the new by reference array with a new shape.  Is the old shape ever removed from the scene?  I assume it is no longer of use since the old data is copied to the new array.

I don't understand what's going on in the updateData() method when (length == maximumPoints*2) but I am not sure that is relevant.

I notice in updateData(), the code manually replicates the previous vertex if the length > 1.  If the next point is always going to be a segment formed with the previous vertex, I suggest you switch to a LineStripArray with a single strip.  This is will substantially reduce the memory used.  It will also completely change the length and reallocation logic.

I suspect the issue is related to the maximum number of vertices being reached and the array replication and shape replacement.  Is there a way to use the ElementTrail so that it is initially allocated with a large enough number of vertices so that the reallocation code is not run?  This may help isolate the problem to this area.

Check the points array contents.  I suspect the gaps grow (perhaps doubles) and are all zeros.

Mike

I am stumped.  There are a huge number of missing vertices and yet it seems to pick up where it should.  Would it be possible to share the Element source?  Or better yet a full example?

I will look at ElementTrail in detail later, but here are a few observations.  There appears to be OpenGL code in the class.  Are you using Java3D for rendering?  The reason I ask is there appears to be OpenGL line drawing code in your class and you are having problems drawing the line.  The Element superclass seems to take care of the Appearance.  This is where the LineAttributes can be set (solid line, dashed line, etc) if Java3D is doing the rendering.

I see that init() replaces the LineArray and that init() is called elsewhere.  When using by reference, I cannot think of a reason why the LineArray would need to be replaced.  Generally speaking, the valid vertex count does not need to be set if you are rendering all of the vertices (unless perhaps the by reference array size is changing?).  If you are rendering only a subset of the vertices, perhaps that is part of the problem?

In ElementBox, there is a flag from Primitive that is being used incorrectly as a vertex format flag:

This has a value of 32, which J3D interprets to mean that you will be supplying texture coordinates (TEXTURE_COORDINATE_2).

When you create the geometry, you can also specify that you will supply vertex colors (another vertex format flag).  If you set the lines to be a sequence of colors (red, yellow, blue, green, purple, ... repeat) you would be able to see that the red segment is there, the yellow segment is there... oh the blue one is missing (for example).  Knowing the pattern of missing segments may help in isolating the problem.

Mike

This sounds to me like the data within the line array is being compromised somehow.  Is the LineArray created with INTERLEAVED and/or BY_REFERENCE by chance?  If so, what is the source of the by reference data?

Is the data created before being rendered or is the attractor an animation (updating the geometry over time)?

Are the two geometries (line array and quad array) assigned to different Shape3Ds, or shared by a single Shape3D? (I realize you stated that there is nothing in common, but I wanted to double check this scenario.)

I would try assigning a sequence of colors to the line segments to see if there is a pattern to the missing segments.

Mike

I believe the J3D sorting stuff primarily deals with how transparent objects are sorted relative to opaque objects.  Check out the View class.  When using transparent objects that need to be sorted with opaque objects, I use:

However, this is on a geometry basis (not vertex) so I doubt this is it.

If the box normal code is the only thing that seems to make the problem show up, could you post that code (assuming there's more).  Is there anything the two shapes might share?  Is it possible that the LineArray has normals assigned (that could make segments disappear)?

Edit: If you change the view position (using a keyboard behavior for example) does the nature of the problem change with the view?

Mike

Thanks for the clarification.  I certainly did not understand the problem.  Changing the quad should have no affect on the line array unless... Are you applying the line array to an oriented shape?  I wonder if it has to do with rendering settings (sorting issues perhaps?) rather than geometry.  I would try using a Shape3D and also try changing the line attributes to make the line 2 or more pixels instead of one.  I realize your requirements might need billboarding this may help isolate the issue.

Are you using an early version of J3D or a released version?  Perhaps a webstart demo or download would help verify it is not a video card driver.

This is a strange problem.  Sorry I don't have anything concrete answers.

Mike

Help me understand something.  When you use QuadArray.NORMALS but don't give it normals it looks bad, right?  But your code in the most recent post shows the same normal being applied to the four vertices within the loop.  Assuming your are using NORMALS and you are assigning the coordinates and normals (and you are certain the normals are unit vectors in the right direction) then the all white box might be related to appearance and lights.  Just to be certain, I would simplify the geometry down to a single quad to make sure that works.

What type of lights are you using and have you assigned an appearance/material to the shape? 

Mike

P.S I don't know much about the picking API, so I can't really help much more there.

Malohkan, The flags of the QuadArray constructor should not use Primitive.ENABLE_GEOMETRY_PICKING.  That flag is a capability indicator for Primitive subclasses (QuadArray is not a Primitive).  The flags on the constructor are used to specify the information available for each vertex.  When you specify QuadArray.NORMALS, you need to generate normals and assign them to the geometry.  If you want to allow picking on the QuadArray, you will need to set the capability (Node.ALLOW_PICKABLE_..., and ENABLE_PICK_REPORTING) on the shape that uses the QuadArray for it's geometry.

The alternative is to use a Box primitive.

Mike

Shawn, I ran it on a crappy old system (256M, 1GHz, 32 Meg Graphics card) and it ran pretty well.  I did manage to crash into a pillar and my character fell off the flying thingie.  The character sparked as it skidded on the ground and tried to float back to the flying thingie but never made it.  It wasn't clear how I was supposed to respawn or at least get up and get back on.  The controls took a moment to figure out, but the old Quake days came back to me (mouse and keyboard combo).

Mike

[p.s. I you need improved particles, I have just the thing for you ;-) ]

That's interesting.  When I asked earlier, the answer was no.  See http://forums.java.net/jive/thread.jspa?forumID=70&threadID=4723&messageID=42803#42803.  I would not call the scene graph the BVH.  Is that our difference?

Mike

See if this discussion helps you: http://forums.java.net/jive/thread.jspa?forumID=70&threadID=16195.

Mike

"Five Balltree Construction Algorithms," Technical Report TR-89-063, International Computer Science Institute, Berkeley, CA, November 1989.  [http://http.icsi.berkeley.edu/ftp/global/pub/techreports/1989/tr-89-063.pdf]

"Using Dynamic Bounding Volume Hierarchies To Improve Efficiency of Rigid Body Simulations', Robert Webb and Mike Gigante.
[http://portal.acm.org/citation.cfm?id=135556&dl=ACM&coll=ACM&CFID=74193598&CFTOKEN=33406427].  I had to order a hardcopy (cannot find an online version).

Google 'Gino Van De Bergen'

Mike

DP,
I was trying to justify the possibility that using the scene graph as a basis for the BVH was reasonable for applications with relatively static scenes.  I have no first hand knowledge that IMI did what I described (sorry if that was not clear).  My physics stuff does the weird stuff (with axis-aligned bounding boxes (AABB) and a binary tree).  Java3D does not reveal a BVH, so one would have to manage the volumes within the application (presumably with BoundingBox and the collision bounds) using the scene graph.

The severely overlapping volumes is a common issue in a BVH implementation.  Because I selected 'minimum added volume' as the cost function to determine the 'best' tree location, the tree does need to be rebuilt occasionally if the objects are long lived.

Entire books have been written the subject.

Mike

A while back, I did some research on collision detection and briefly considered using the scene graph as the bounding volume hierarchy (BVH).  [A BVH is used during a broad phase of collision detection to more quickly prune away distance objects from collision consideration.  Other tighter volumes up to and including the actual geometry are typically used in the narrow phase.].  There are many ways to create a BVH depending on the application (binary trees, n-ary trees, spheres, axis aligned boxes, oriented bounding boxes, etc.  Since the BVH is used for the broad phase of collision detection and my situation (a particle system) could involve many shapes, I elected to go with a separate axis aligned box BVH.  This was mostly because the particles could have little or no locality coherence (they could go anywhere).  I also elected to use 'subtree volume' as the cost function to determine how to build the BVH for the same reasons.  If an application has a relatively static scene, then the scene graph seems like it could double as a fine BVH.  It has a collision bounds at each level and already has a tree structure.  Ultimately, the decision is primarly about the perfomance of the collision detection.

Mike 

Thanks for the feedback.  I am always happy to hear back from JDJ readers.  The only behavior that really matters in the current code base is the 'clock tick' generated each frame.  I have assumed that would be replaced with a render loop call.  If Xith uses the vector math package from Sun (I believe it does, right?)  what other mismatches did you encounter?  The latest release does use the view platform boundary entry/exit support from behavior, but I didn't expect every feature to port.

Thanks,
Mike

The final version of Genesis FX Personal Edition and Developer Edition version 1.1 is now available.

Get it here: http://www.indietechnologies.com

Genesis FX is a particle system for Java 3D.

Mike

I have made no decision yet because I have been unable to download Xith (due the bandwidth problems noted on this forum).  The similarity to Java 3D is a big attraction.  I am in the process in reviewing the long term release plan.  Version 1.1 was just released tonight and I would like to get the next release out in six months or less.  All releases will have a free personal edition.  A distribution like a commercial game or open source project requires a single developer license.  I'll need to learn more about Xith prior to making the decision.

Mike

Would Xith3D users be interested in a port of this? www.indietechnologies.com

Have a look at javax.media.j3d.Switch.  It is a special kind of group that uses a bit mask to determine which children are visible.

Also have a look at this to see if it's what you need: http://www.alphaworks.ibm.com/tech/river

The second and final beta of the Genesis FX Personal Edition is now available. This beta has complete documentation including a new step by step installation guide for Eclipse and NetBeans. Several minor bugs were squashed, a few of the examples were improved, and one new example was added.

Get the beta here: http://www.indietechnologies.com/store/getgenesisfx.html

One known issue remains for *nix platforms running some of the examples. A FileNotFoundException is thrown due to what appears to be a defect in the MilkShape3D loader. This will be addressed in the final version.

Please report any issues or questions on our forum.

Mike

The Sun Java 3D team will be showing a demo created with the Genesis FX particle system.  A video of the demo and a technique paper describing how it was done is here: http://www.indietechnologies.com . Stop by the booth if you are at JavaOne. The image quality is better than the video can show and there's no other way to see the 'particle time' pausing and circle strafing of the particle effects.

Mike

Genesis FX Personal Edition beta is now available.  This version adds 20 prebuilt special effects and many new features.  Get the beta here: http://www.indietechnologies.com/store/getgenesisfx.html.

Mike

This is a screen shot (movie is here: http://www.indietechnologies.com/movies/lostsoulspreview.mpeg) of one of our examples for our next release.  The demo is patterned after the Doom and Heretic/Hexen lost souls so is on the 'dark and gloomy' side.  Uses Java 3D.  Would appreciate feedback.

 

Jeff is right if the Quaternion is used to represent an orientation.  On the surface, it appears that the quaternions may be used to represent axis rotations.  I included an overview of Java 3D quanternions in this article that might prove useful (http://jdj.sys-con.com/read/99792.htm).  The quaternions are covered in the section entitled 'Slicker than Euler' on page 3.

Mike