Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (755)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3
1  Java Game APIs & Engines / Java 3D / Re: [GenesisFX] Deploying via JWS with OSX on: 2008-03-25 17:39:39
Check the level of Java 3D installed on OSX.  I believe that method was introduced a while ago (J3D 1.3 or 1.4?).

2  Java Game APIs & Engines / Java 3D / Re: Water appearance? on: 2006-11-08 21:47:53
Nobody? Nobody has Java3D water?

Check out this article:

Perhaps you are looking for something like this:

or this:

Note that transparency and animation can really affect framerate.

3  Java Game APIs & Engines / Java 3D / Re: FlyingGuns uses GenesisFX on: 2006-10-11 16:54:49
using layered imposter rendering?

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?

4  Games Center / Showcase / Re: Got a smoke? on: 2006-08-14 23:20:11
4 rays per sprite (every corner) are used for realistic shading.
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?

5  Java Game APIs & Engines / Java 3D / Re: LineArray and QuadArray not playing nicely together on: 2006-08-08 02:41:21
Great to hear. 
6  Java Game APIs & Engines / Java 3D / Re: LineArray and QuadArray not playing nicely together on: 2006-07-30 14:36:14
Well it's not done in a behavior... It's just in another Thread.  There's a Thread.sleep() between the calls to addPoint(). 

I believe Java3D has a few problems (namely geometry locking: 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.

7  Java Game APIs & Engines / Java 3D / Re: LineArray and QuadArray not playing nicely together on: 2006-07-29 16:37:55
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.


8  Java Game APIs & Engines / Java 3D / Re: LineArray and QuadArray not playing nicely together on: 2006-07-29 04:41:09
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?
9  Java Game APIs & Engines / Java 3D / Re: LineArray and QuadArray not playing nicely together on: 2006-07-28 12:32:43
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:
qa = new QuadArray(data.length * data[0].length * data[1].length,
               QuadArray.COORDINATES | Primitive.ENABLE_GEOMETRY_PICKING);

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.

10  Java Game APIs & Engines / Java 3D / Re: LineArray and QuadArray not playing nicely together on: 2006-07-27 23:54:51
When I spin the camera around nothing changes.  I can zoom in and out and spin all around and get the camera between things and nothing changes.  It's as if I removed certain segments from the scene altogether.

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.

11  Java Game APIs & Engines / Java 3D / Re: LineArray and QuadArray not playing nicely together on: 2006-07-26 02:55:59
If this has to do with sorting issues, where could I find more information about how to tweak how Java3D does its sorting?  I assume there are some flags related to this.

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?

12  Java Game APIs & Engines / Java 3D / Re: LineArray and QuadArray not playing nicely together on: 2006-07-25 23:24:30
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.

13  Java Game APIs & Engines / Java 3D / Re: LineArray and QuadArray not playing nicely together on: 2006-07-24 22:07:03
In my program here I have a LineArray displaying a simulation of a nice little Lorenz attractor.  Also near the bottom is a blue box built by a QuadArray.

If I create the box with:
qa = new QuadArray(data.length * data[0].length * data[1].length,

and don't give it any normals, I get the problem shown in the not-so-pretty image. 

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? 


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

14  Java Game APIs & Engines / Java 3D / Re: LineArray and QuadArray not playing nicely together on: 2006-07-24 15:50:12
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.

15  Games Center / Archived Projects / Re: Cosmic Birdie Tech Demo Release on: 2006-07-12 01:08:42
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).


[p.s. I you need improved particles, I have just the thing for you ;-) ]
16  Java Game APIs & Engines / Java 3D / Re: Physics Modeling - Java3D suitability on: 2006-07-07 19:19:11
That is incorrect. Java3D does have and exposes the BVH (bounding volume heirarchy) and we use it in our traversal down to the shape level. 

That's interesting.  When I asked earlier, the answer was no.  See  I would not call the scene graph the BVH.  Is that our difference?

17  Java Game APIs & Engines / Java 3D / Re: Alpha Channel in a Texture on: 2006-07-05 14:04:45
See if this discussion helps you:

18  Java Game APIs & Engines / Java 3D / Re: Physics Modeling - Java3D suitability on: 2006-07-02 20:26:32
Got a few links that are specific to my question? Im interested in that area at the moment...


"Five Balltree Construction Algorithms," Technical Report TR-89-063, International Computer Science Institute, Berkeley, CA, November 1989.  []

"Using Dynamic Bounding Volume Hierarchies To Improve Efficiency of Rigid Body Simulations', Robert Webb and Mike Gigante.
[].  I had to order a hardcopy (cannot find an online version).

Google 'Gino Van De Bergen'

19  Java Game APIs & Engines / Java 3D / Re: Physics Modeling - Java3D suitability on: 2006-07-01 03:17:17
Ah ok, so you are using the bounding volume heirarchy to do wide area collision detection? Nice....
Why doesn't any physics engine out there at the moment do that?
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.

20  Java Game APIs & Engines / Java 3D / Re: Physics Modeling - Java3D suitability on: 2006-06-30 03:23:13
...rigid physics system that is directly driven off of the Java3D scene graph structure.  ...

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.

21  Java Game APIs & Engines / Xith3D Forums / Re: Particle system - Do you use it? on: 2006-06-02 13:50:30
I actually started a port of some of your earlier source bases.  I didn't find enough of a match to pursue if at the time.  When I tried, Xith had , limited to no behavior support so I was handling it all from the render method.   I really have enjoyed your system and hope to see it Xithified at some point.

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.

22  Java Game APIs & Engines / Java 3D / Re: Genesis FX Personal Edition Beta 2 available on: 2006-06-01 12:31:23
The final version of Genesis FX Personal Edition and Developer Edition version 1.1 is now available.

Get it here:

Genesis FX is a particle system for Java 3D.

23  Java Game APIs & Engines / Xith3D Forums / Re: Particle system - Do you use it? on: 2006-06-01 03:28:36
...have you decided if you'll do the port ? Will it be free ? Which license ?

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.

24  Java Game APIs & Engines / Xith3D Forums / Re: Particle system - Do you use it? on: 2006-05-25 00:23:50
If a sufficient number of people use/would be interested into that I may do something so that's more easy and straight-forward to use.

Would Xith3D users be interested in a port of this?
25  Java Game APIs & Engines / Java 3D / Re: Question about switching visible content on screen on: 2006-05-24 17:26:21
Have a look at  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:
26  Java Game APIs & Engines / Java 3D / Genesis FX Personal Edition Beta 2 available on: 2006-05-24 02:11:15
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:

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.

27  Java Game APIs & Engines / Java 3D / JavaOne Java 3D demo on: 2006-05-13 20:48:02
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: . 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.

28  Java Game APIs & Engines / Java 3D / ANN: New free version of Java 3D particle system on: 2006-04-25 01:45:36
Genesis FX Personal Edition beta is now available.  This version adds 20 prebuilt special effects and many new features.  Get the beta here:

29  Games Center / Archived Projects / Feedback request: Particle Effects on: 2006-04-14 19:51:55
This is a screen shot (movie is here: 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.

30  Game Development / Newbie & Debugging Questions / Re: Quaternion rotations and gimble lock on: 2006-03-12 04:17:25
... the whoel point of Quaternions is that they *don't* suffer from gimble lock.

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 (  The quaternions are covered in the section entitled 'Slicker than Euler' on page 3.

Pages: [1] 2 3
DesertCoockie (36 views)
2018-05-13 18:23:11

nelsongames (82 views)
2018-04-24 18:15:36

nelsongames (74 views)
2018-04-24 18:14:32

ivj94 (755 views)
2018-03-24 14:47:39

ivj94 (85 views)
2018-03-24 14:46:31

ivj94 (626 views)
2018-03-24 14:43:53

Solater (101 views)
2018-03-17 05:04:08

nelsongames (182 views)
2018-03-05 17:56:34

Gornova (408 views)
2018-03-02 22:15:33

buddyBro (1068 views)
2018-02-28 16:59:18
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!