Skip to main content

Java3D Particle System JDJ article

32 replies [Last post]
mnjacobs
Offline
Joined: 2003-06-13

I am in the process of writing an article that covers particle systems. I'd appreciate ideas of topics that you think should be included. To give you an idea of what it planned, check this out: http://mnjacobs.javadevelopersjournal.com/read/1033148.htm.

Thanks for any and all feedback.
Mike

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
aces
Offline
Joined: 2003-07-17

>Alessandro, Can you help me understand how you were able to link the step down in the video memory graph to recycling of particles?

In BlackHole demo seems the particles were not been recycled. The new particles were growning both system memory and Video Card memory. After a GC, both memories were freed. I did not analyse BlackHole code yet, but I guess the recycle was not working properly. I did note it with other demos.

You can pick our D3D port to DX9.0 here
https://j3d-core.dev.java.net/source/browse/j3d-core/binaries/?only_with...

if you like to use NVidia profile tool :
* NVPerfHUD (for DirectX 9.0 C) is available free here
http://developer.nvidia.com/object/nvperfhud_home.html

* Make a .BAT file to launch your application, and drag-and-drop it over NVPerfHUD icon to launch it.

Your demos will help me a lot to fine tune this D3D port, alongside with a application for geologic data visualization I am also working.

mnjacobs
Offline
Joined: 2003-06-13

Alessandro,I did observe substantial system memory use when the branch group changed a lot (http://www.javadesktop.org/forums/thread.jspa?threadID=13341&messageID=9...). The black hole demo changes the branch group substantially, so I am guessing this is the source of the memory growth.

Since I changed the (unreleased) design to use a Switch group, the memory use has declined quite a bit. When I get to the optimization phase of my project, I will have a look at NVPerfHUD.

Thanks,
Mike

mnjacobs
Offline
Joined: 2003-06-13

LeW, Could you try one thing on OpenGL? The particle system implementation forces a pixel size of 2. Could you update MotionBlurredParticleSystem.createAppearance(), and change the line:

LineAttributes la = new LineAttributes(2, LineAttributes.PATTERN_SOLID, true);

to be:

LineAttributes la = new LineAttributes(1, LineAttributes.PATTERN_SOLID, true);

and see if that addresses the OpenGL issues?

Thanks,
Mike

Anonymous

I did the change.
picture via OGL looks very similar to previous one:
http://legionary.pisem.net/others/particle2_shot1.jpg

aces
Offline
Joined: 2003-07-17

Some new pics. This time showing Java3D D3D Dx9 renderer with NVidia NvPerfHUD profile tool and Smoke and Tornado demos.
Very interesting ;)

http://paginas.terra.com.br/educacao/alessandroborges/particles/particle...

mnjacobs
Offline
Joined: 2003-06-13

Alessandro, Can you help me understand how you were able to link the step down in the video memory graph to recycling of particles?

The smoke demo frame rate seems low. I'll give it a try with my fps counter tonight. Could the GPU bottleneck be related to the DX9 port you are working on? ;-) I ask because the Tornado uses *many* more smoke particles than the Smoke demo. The Tornado does not choke your FX5700? The Smoke demo adjusts the transparency and scale of the smoke particles much more frequently, so perhaps that's the bottleneck.

Mike

mnjacobs
Offline
Joined: 2003-06-13

Alessandro, I am running a substantially less powerful video card and the smoke demo runs at 24 fps. Could the HUD or DX9 port be affecting the frame rate? Here are my pitiful system stats:

* Sun Java JRE 1.4.2_03
* Sun Java3D 1.3.2 DirectX version
* Microsoft Windows XP Home Edition (Version 2002, SP1)
* Microsoft DirectX 9.0b (4.09.0000.0902 via dxdiag)
* 1 Ghz AMD Athlon Processor
* 256 MB of RAM
* nVidia GeForce2 GTS (32 MB)
* All hardware accelleration enabled

To use the same frame rate measurement, add this to the createSceneGraph() method on the example:

FrameRateBehavior fps = new FrameRateBehavior();
fps.setSchedulingBounds(bounds);
objRoot.addChild(fps);

Mike

aces
Offline
Joined: 2003-07-17

Mike, I guess my low frame rates is due my system. :(
To get my mobo stable I had to drop down AGP rate to 1x, where the optimal should be 8x - this a bug in my mobo, nothing related to OpenGL,DirectX or Java3D.
In normal use AGP 1X is OK, but with heavy weight applications, like Tornado and Smoke, it miss the power of AGP 8x. I guess is time for hw upgrades ;) .
I have more FPS with OpenGL, but as noted before, D3D runs smoother even at low fps, and OpenGL has more latency and runs jumping, even at much higher fps.

By the way, NvPerfHUD takes less than 1% of fps. I've got the same numbers with or without NvPerfHUD, using FRAPS to get fps values.

My system specs :

* Sun Java JRE 1.5.0_03
* Sun Java3D 1.3.2 with D3D DirectX DX9.0c renderer (beta)
* Microsoft Windows 2000 Professional (SP4)
* Microsoft DirectX 9.0c (release October 2004)
* 1.1 Ghz AMD Duron Morgan Processor (a Athlon XP with 192kb cache)
* 768 MB of RAM
* NVidia GeForce FX 5700LE (128 MB) @ (250/400MHz)
* VDriver ForceWare 76.80 (beta - OpenGL 2.0)
* All hardware accelleration enabled

Thank you

mnjacobs
Offline
Joined: 2003-06-13

> ... and solving a set of nonlinear
> equations for each position using Newton-Raphson
> iterations with Runge-Kutta 4 time-stepping.

Cool. Your approach is appropriate for scientific simulations like your air flow applications. My article will keep it simpler... Euler's approach to integrating ODEs. I think this is appropriate for a tutorial and games.

Mike

nvaidya
Offline
Joined: 2004-08-03

Yes, Euler will be just fine because the interest will be more on the macro special FX rather than local point-wise accuracy.

mcneillk
Offline
Joined: 2005-02-03

Do you know the status of the J3D.org repository code?

Would there be a way to get it into the community incubator?

I say this in part because I have modified (debugged mostly) and used the USGS DEM loader and similar code. J3D.org seems too stagnant -- and yet [b]the repository code is valuable[/b] (Particles and Geometric utilities, etc.).

kimerinn
Offline
Joined: 2003-10-27

> Do you know the status of the J3D.org repository
> code?
>
> Would there be a way to get it into the community
> incubator?

The only thing I know that j3d.org repository is Open Source. I think, before putting it into incubator, we need to ask its authors. Hey, Justin Couch and Alan Hudson! Do you allow to put your j3d.org codebase (not Xj3D) to next generation java3D codebase ???

mnjacobs
Offline
Joined: 2003-06-13

> FYI, there is some particle code I wrote a while back
> in the j3d.org repository. It seems to cover most of
> what you touch upon.

Dan, Because the code would be included with an article and appeared to be in alpha, I felt I could not adequately represent it. The j3d particle system (as far as I could tell) does not seem to include arbritrary Shape3D objects as particles which was a feature I was determined to include.

By the way, thanks for your past work and the book.
Mike

Daniel Selman

It's true, I did not implement a "Shape3D per particle" system, but the
code was designed to support that case. Theoretically you can have any
complex geometry per Particle.

I'd be happy to help out if you have questions.

Dan

java3d-interest@javadesktop.org wrote:
>>FYI, there is some particle code I wrote a while back
>>in the j3d.org repository. It seems to cover most of
>>what you touch upon.
>
>
> Dan, Because the code would be included with an article and appeared to be in alpha, I felt I could not adequately represent it. The j3d particle system (as far as I could tell) does not seem to include arbritrary Shape3D objects as particles which was a feature I was determined to include.
>
> By the way, thanks for your past work and the book.
> Mike
> ---
> [Message sent by forum member 'mnjacobs' (Mike Jacobs)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=62797&#62797
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
> For additional commands, e-mail: interest-help@java3d.dev.java.net
>
>

--
ILOG... Changing the rules of business

Direct Line: +33 1 49 08 36 30
Fax : +33 1 49 08 35 35
Email : dselman@ilog.fr - URL : www.ilog.fr
9, rue de Verdun, B.P. 85, F 94253, Gentilly Cedex

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

mnjacobs
Offline
Joined: 2003-06-13

Dan, I do have a question regarding the j3d.org particle system. I cannot seem to access the site in the last few days to confirm my memory, but I recall there was a series of possible particle systems based on the underlying geometry arrays (TriangleArray, QuadArray, etc). Is this what you meant by 'any complex geometry per Particle'?

Thanks,
Mike

Daniel Selman

Mike,

As you say, j3d.org is down right now, luckily I found a mirror so I
don't have to rely on my failing memory!

http://www.math.nyu.edu/phd_students/meyersr/links/j3d/index.html

I did only provide Particle implementations based on BY_REF geometry
into a single Shape3D. Note that Particles are simple structs for high
performance and include most of the attributes required for basic
particle systems.

The interfaces however allow a ParticleSystem to be represented by any
(root) Node in the scenegraph (see the getNode method).

So, for example, if you look at the TriangleArrayByRefParticleSystem
you'll see that it creates a single Shape3D with a BY_REF geometry
array. It's getNode method return the single Shape3D to be added to the
scenegraph.

When the 'update' method is called on the
TriangleArrayByRefParticleSystem it loops through its Particles and
allows the ParticleFunctions to write to the Particles in the system.
The TriangleArrayByRefParticle implementation provides updateXXX methods
that can *also* write into the BY_REF geometry array hosted by the
TriangleArrayByRefParticleSystem.

So... in the case where a Particle was to be represented by a Cube (for
example) - you'd:

- Create a CubeParticleSystem class and subclass ParticleSystem
- Create a CubeParticle class that subclasses Particle and adds a
Shape3D for each Particle. You might choose to also add a TG to move the
Particle.
- The 'getNode' method of CubeParticleSystem returns a BranchGroup or TG
that contains all the CubeParticle Shape3D instances
- In the 'update' method of CubeParticleSystem you'd allow all your
registered ParticleFunctions to process your CubeParticles. Processing
would consist of updating the geometry or perhaps better, just updating
the TG to move the Shape3D for the particle.

Behavior in all cases is implemented in ParticleInitializers and
ParticleFunctions. This allows these implementations to be reused - not
matter how the ParticleSystem is being rendered (cubes, or BY_REF etc).

Of, course, with lots of complex geometry your scenegraph is going to
get complex very quickly and performance will probably suffer, compared
to the BY_REF approach. I specifically designed the classes and
interfaces to support both however.

Best of luck!

Dan

java3d-interest@javadesktop.org wrote:

> Dan, I do have a question regarding the j3d.org particle system. I cannot seem to access the site in the last few days to confirm my memory, but I recall there was a series of possible particle systems based on the underlying geometry arrays (TriangleArray, QuadArray, etc). Is this what you meant by 'any complex geometry per Particle'?
>
> Thanks,
> Mike
> ---
> [Message sent by forum member 'mnjacobs' (Mike Jacobs)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=63066&#63066
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
> For additional commands, e-mail: interest-help@java3d.dev.java.net
>
>

--
ILOG... Changing the rules of business

Direct Line: +33 1 49 08 36 30
Fax : +33 1 49 08 35 35
Email : dselman@ilog.fr - URL : www.ilog.fr
9, rue de Verdun, B.P. 85, F 94253, Gentilly Cedex

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

paulby
Offline
Joined: 2003-06-13

The NWN loader written by Artur https://sourceforge.net/projects/nwn-j3d/ includes a particle system. I don't know how generic the implementation is but it might be a useful reference.

Anonymous

> I am in the process of writing an article that covers
> particle systems. I'd appreciate ideas of topics
> that you think should be included. To give you an
> idea of what it planned, check this out:
> http://mnjacobs.javadevelopersjournal.com/read/1033148
> .htm.
>
> Thanks for any and all feedback.
> Mike

video looks great.
any javad3 "particle demo/sample" available?

mnjacobs
Offline
Joined: 2003-06-13

The article is now available at the JDJ website: http://java.sys-con.com/read/99792.htm. The source code including the examples are also available: http://res.sys-con.com/story/jun05/99792/source.html (link on the bottom).

Enjoy,
Mike

aces
Offline
Joined: 2003-07-17

I guess this is *very* good test case for finding bottlenecks in Java3D renderer on complex systens.
Good work, Mike ;)

Anonymous

..working nice :-)

BTW, PointParticleSystemExample2 looks quite different via d3d and openGL, see shot:
http://legionary.pisem.net/others/particle_shot1.jpg

mnjacobs
Offline
Joined: 2003-06-13

LeW, That is very different. Be sure you have the latest driver for your card. I'm pretty sure any changes between platforms like that are related to the quality of the video drivers.

The other possibility is to check that you are running J3D 1.3.2. The readme.txt file contains the list of system configurations used to test the code. The Linux box did have some graphics artifacts especially with the clouds. We assumed it had to do with the driver.

Mike

Message was edited by: mnjacobs

Anonymous

my configuration:

OS Version: WinXP
Video Card Model: Intel(R) 82865G Graphics Controller
Video Driver release: 6.14.10.3924 (2004.09.30)

Video size & color depth : 1152x864, 32bit
java3d 1.3.2
java 1.4.2 (build 1.4.2-b28)
latest DirectX and I think latest OpenGL, because WindowsUpdate offers nothing.

yes, I read readme file, and yes, I understand that particleSystem tested via DirectX only on Windows.

aces
Offline
Joined: 2003-07-17

Congratulation, Mike!
Runs pretty good in a Win2k with Savage S4.
I tested using our beta D3D DirectX 9.0 renderer for J3D 1.3.2

Pics here:
http://paginas.terra.com.br/educacao/alessandroborges/particles/particle...

mnjacobs
Offline
Joined: 2003-06-13

Alessandro, Thank you!

Mike

pepe
Offline
Joined: 2003-06-10

yum. please release demos as webstart applications, so that everyone can have a look at it without any hassle.

herkules
Offline
Joined: 2003-06-12

The idea is to put the sourcecode to an Java3D incubation project :)

The tornado looks great!

Daniel Selman

FYI, there is some particle code I wrote a while back in the j3d.org
repository. It seems to cover most of what you touch upon.

Best of luck,

Dan

java3d-interest@javadesktop.org wrote:

>The idea is to put the sourcecode to an Java3D incubation project :)
>
>The tornado looks great!
>---
>[Message sent by forum member 'Herkules' (Joerg Plewe)]
>
>http://www.javadesktop.org/forums/thread.jspa?messageID=62624
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
>For additional commands, e-mail: interest-help@java3d.dev.java.net
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

kimerinn
Offline
Joined: 2003-10-27

Well, why not to put entire j3d.org codebase to java3D incubator? It has many useful tools and utilities.

> FYI, there is some particle code I wrote a while back
> in the j3d.org
> repository. It seems to cover most of what you touch
> upon.

kcr
Offline
Joined: 2004-03-17

> Well, why not to put entire j3d.org codebase to java3D incubator? It has many useful tools and utilities.

Code put into the j3d-incubator project needs to be done by the Copyright owner of the code who, under the terms of a signed Joint Copyright Assignment, is granting a joint Copyright to Sun, so that we can redistribute the code under a BSD license. Since much of the code in J3D.org is donated from various sources, and is under LGPL license, this is either impractical or impossible.

-- Kevin

nvaidya
Offline
Joined: 2004-08-03

Aha ! an interesting topic. Will look forward to reading the article.

How about an RFE for PointSprites in Java3D 1.4 ?

Here are a couple of stream particle animations that I did many moons ago with Java 3D.

http://www.freewebs.com/matspring/ptrackone.htm

The computation of the particle positions in these cases in some sense is relatively very numerically intensive. It typically involves storing the entire dataset (as many as a million cells) in a Bounding Volume hierarchy to detect if the particles have exited the domain, and solving a set of nonlinear equations for each position using Newton-Raphson iterations with Runge-Kutta 4 time-stepping. The rendering here is in the form of animated pulses sliding along lines and the lines themselves are Phong-lit using a 2D texture map. The rendering can be changed on the fly to show single particles, lines periodically growing from the emitter like the growing of grass etc.

kcr
Offline
Joined: 2004-03-17

> How about an RFE for PointSprites in Java3D 1.4 ?

I just added it to the list.

-- Kevin