I’m wondering if there were some tests done to gather some performance on the particle emitters in jME3.
As it is I make a spiral galaxy where each sun is a particle emitter (around 1500). Each sun is surrounded by a “smoke” effect. So that’s 3000 particles. On top of that, the galaxy slowly spins. Barely noticeable but it does.
At the moment I get 21 FPS with a GeForce 480 GTX.
I’m wondering if it’s either the present state of the engine or the emitter that is slowing me down. I wouldn’t think 3000 small particles would buckle my computer’s knees. Anything is possible I guess.
Also, there is nothing else except those “suns” and their envelopes.
Suggestions and ideas?
I’m wondering if there were some tests done to gather some performance on the particle emitters in jME3.
you know, with the quality loss of using gl_points, you could get hundreds of thousands of “suns” likely with better performance.
you could even do distance checks to the camera and apply particles to close “suns”, thereby limiting the number of particles and increasing the number of suns.
sorry, this was just a tangent, i dont know any numbers on the particle system in jme3, but the above was my solution to a similar problem in JME2
Yes. Distance rendering is planned. I’m not just at that point right now. Generating a spiral galaxy with “suns” dissipated along each arm’s length was tough already.
The way I see it for the future right now is, as the ship gets closer, the movement speed scale will drop but the small increments will zoom-in on the sun and its solar system. At a certain distance the player will leave the galaxy space and enter the solar space.
Anyway, that’s at some future point, although it’s not that far.
I will look into gl_points tomorrow. If you have links or pointers on that please post them. I will look it up.
You simply have to much objects, each particle is a boject, the fps dies because it does to much statechanges for rendering
btw around 3000 objects is what i feels to be the limit, If this it is static (on the same place) you could try:
- Make the effect in model programm, export as animated model
- Unanimated mdoel with all particles, add movement with a vertexshader
I just ran it and hit close to 4000 (3884 iirc) and FPS was at 8. LoL The game randomize the stars in the galaxy. I successfully ran with 10000 some time ago, but fps was 0-1…
The thing is, there are alternatives to the way I’m doing it right now, but I’m leaning jME right now and I don’t know half of half of what I should know. So it’s a learning experience as I go along. I wish I knew more, a lot more.
What I’ve been thinking about is to have the area closest to the camera to be “clear and visible”, but blur things farther than X pixels or whatever. The thing is, I have no idea how to properly add what’s beyond so it looks good. I could approximate the galaxy’s arms with some blurry pngs or whatnot (if you have played Spore and attained space, I want it to look a bit like that) but everything is randomized in the galaxy generation. The number of arms, number of suns, rotational angle of the arms, etc, etc. So It will be tough to outline the arms.
Anyway… I’ll think of something. But, if you guys have suggestions, don’t hesitate to throw them at me. If it’s running slow here, I can’t imagine how it would run on an every-day-computer… choke
Render the sky/space scene one frame to a texture and use that for the sky, as long as you don’t move much from your planet (assuming as in spore) there should not be any problem then. I suggest to take a look at the test package. (Of course this is a bit tricky and nto the easyest thing to be done, but on the pro is that you can have much more elements then in the sky without further slowing down.)
For the spin of the galaxy, just rotate the skybox then ^^ I bet only very few would recognize this trick.
(Or occaisionally redraw but only if you really have to)
Here are 3 screenshots of a galaxy generated.
Well, I dont mean to hijack your thread, but I thought I would bring in a picture from some of my own work to compare and contrast with your own.
Ultimately I am trying to point you in the right direction to have a really great project.
First of all, I want to say that your galaxy looks really great, especially the stars which have good quality as well as distribution. This quality level is lacking in my own implementation (albeit not impossible for me to change, i just never got that far)
So, basically, by using gl_points, I have over 100,000 “stars” on screen with over 100 fps
In reality, through using detail layers, I have over 5 million stars. You see, when you zoom in, more stars are spawned. This galaxy is also Seed generated, so every star will be in the exact same position next time i start the program, even the 5 million stars will be in the same positions.
By using a combination of our two ideas, I could see you having a really amazing galaxy.
If you’re to give good tips then by all means hijack.
I take it gl_point is in the .vert shader file and it’s openGL “language”, so I’ll look into that.
Thanks for the info. If you want to paste some of the gl_point you use feel free to do so.
well actually, i take that back. gl_points is what the Infinity Admin with the Infinity Project is using for his stars, I use (the equivalent?) Point object from jme2 (which may be based on gl_points?)
It is created in such a way: Point p = new Point(“name”,location_array, null, color_array, null);
This would take in an array of vectors and put points at each location. 1 point object can take in TONS of locations.
Here is the tough part though, I never found a way to pick the locations (by picking i mean casting a ray and detecting intersection) without using other geometry. What I did was spawned billboards at close star locations and attempted to intersect those.
Now, in jme3, check out this thread : http://hub.jmonkeyengine.org/groups/development-discussion-jme3/forum/topic/which-class-in-jme3-instead-of-jme2-point/
Also, if anyone has clarification between gl_point and the jme point object, I would love to be schooled.
hope this helps.
Particles in jME3 were mostly designed for low counts ( < 100 ) so that might explain why you have slow-downs.
Since you’re rendering mostly disperse particle emitters, you probably don’t need the built-in sorting that is used in the particle emitter.
Other optimizations are possible as well, like using point sprites or accelerating particle update through OpenCL.
I just found out point sprites were supported in OpenGL since version 1.4 … That means there should be no problem with making them the default in jME3.
That’s great Momoko_Fan. Hopefully that’ll help.
I’ve hit a snag though.
Now that my stars have been converted to points, I can’t do picking on them. The CollideWith method complains it can only be used on Triangles. (Only ‘Triangles’ mesh mode is supported.)
I’ve tried using bounding spheres or using a physicsNode after adding a physic mesh at each point where each sun is but that also failed.
Does that mean I somehow have to revert to something else like a “real” geometry? Maybe I could try to use an invisible geometry but then again I would prefer not. The less clutter there is, the best.
So, what are my options here?
It is probably possible to implement a “CollisionData” implementation for ParticleMeshes. This would require use of partitioning though so it won’t be trivial.
I guess it’s up to you to implement this or not. It sure is out of my limited talent.
I could use an “area test” comparing the clicked-at coordinates to go through any particles near that location I guess.
Anyway, let me know if you plan on working on it or not. It would be very much appreciated to know. If you don’t plan on it then I’ll try to get a fix by myself.
Your lack of reply tells me you will not implement collision with particles any time soon.
Anyone has a suggestion on how I could achieve a similar result?
Sorry I had a reply but I didn’t get a chance to post it.
I am not going to implement this as collision detection with particles is not a common operation, and making it efficient enough for handling large amounts of particles will require sophisticated spatial partitioning.
No problem. I understand that even if that’s not what I wanted to hear.
Maybe I’ll find some way to implement something similar, although I have to admit I have no idea how I could or even where to begin.
This might seem like alot of work, but it might end up being really nice.
What you could do is break the scene up into an octree and then find the intersection with the nodes of the octree and only test inside small sections by spawning boxes or billboards over the star locations and then picking them in small bunches. I do something similar to this in my galaxy however mine is less efficient.
I actually am always spawning/deleting star geometry in the octree surrounding the camera, and then only these geometries are picked. This causes me to not be able to pick far away stars though because they have no geometry spawned on them, only point objects.
You lost me at octree.
I’ll google that and see what I come up with (I’ve heard of it, but I don’t know much about it). If you have links or tuts, send them my way.
As of now, I generate up to half a million points in a galaxy. Since it’s randomized, I generate between 200 000 to 500 000 each time. I do display only 1500 points though with FPS around mid-hundred.
The spiral galaxy generation is pretty much done. I’ve been trying to generate a nice barred galaxy, but so far that has proven more difficult that I imagined. It’s close to be done though. Heavy tweaks are needed to have a nice ring. I might change my outlook on the whole ellipse-filling and go with a torus instead. After that I’ll generate a basic elliptical galaxy (egg-shaped), which should prove much easier.
BTW Eggsworth, if you want to discuss the whole subject on MSN / Steam or otherwise, drop me a line.
basically, imagine a cube.
now, divide this cube into 8 more cubes, at this point you begin subdividing each of these cubes into more cubes depending on a distance threshold from the camera. What you are left with is increased detail around the camera, while far away detail is not brought into rendering as it is unnecessary.
This is the general idea behind an octree, basically it is a complex form of scene partitioning.
how this could benefit you is that in each subdivided box around the camera, you could have increasing layers of detail of stars which would make for a really rich galaxy.
also, it would give you control to spawn geometry for intersection purposes around nearby star locations.