Hardware instancing

Hey all,



In my project I’ve got a ton of simple meshes (all with pretty similar draw state) flying around the world in a physics simulation. Currently performance is choking out at few thousand nodes. I’ve been reading about hardware instancing and I was wondering if anybody around here had ever played with it in JME3. I know it’s been talked about in the forum a few years ago:



http://hub.jmonkeyengine.org/groups/user-code-projects/forum/topic/geometry-instancing/



but it seems a lot has changed with glDrawInstanced and the progress of new OpenGL versions.



Has anyone thought about how to build this into JME3? Is there a better way to move forward with instancing than my current naive approach?



Seeing demos like this makes me drool:

http://vimeo.com/groups/4211/videos/10501999



Thanks!

Well the demo was not renderd realtime, probably or the visible meshes are are product of shaders. (or an animated mesh maybee?)



Fact is most grafficcards start to get really slow afer around 3000 nodes as the rendercalls are slowing them down. So the real problem here is sending the commands to the gpu.



For the meshes in JME3 they are already shared, thanks to the seperation of Geometry-class and Mesh-class (and an intelligent asset-manger)

Actually Empire Phoenix, with hardware instancing you only do 1 call to render potentially millions of identical objects, so thats not an issue.

jME3 does support instancing on the low-level renderer side, all we need is some kind of InstancedGeometry scene graph object or similar, that would take advantage of it. Most important though, is to have a shader that is able to render instanced models.

Hm cool that woudl be rally nice then if that is possible, but as far as I understand that only helps if I have the same object very often so to all our block game programmers this would be really cool)

Hardware instancing is really useful for creating massive lively terrains (and in my case massively awesome data visualizations). The video I posted really WAS rendered in real time on a laptop-level card at 18fps.



What needs to happen to get hardware instancing finished? Is there something I can help with? I don’t have a lot of experience mucking around with JME3’s guts and I’m not terribly gifted at OpenGL extension guts either. I can test and give use case input. I can also probably swing a decent donation from my budget for JME3 to help this get done right.



Right now I have thousands of regular old cubes that I’m attaching to a regular old scene graph nodes. I’m doing an intelligent abstraction for materials that minimizes the number of material objects applied (one for each color group). It shouldn’t be too tough transplant this grouping into InstancedGeometry nodes. I still need to apply individual transformations to em, though.



I’ve said it before, but man…I love this project. Can we move forward on this somehow?

I think I’m still a little confused on some parts of hardware instancing, too. Would I need to use a vertex shader to apply individual transformations? If so, is there a clear way to do that imperatively (i.e. using transformations figured out in my JME3 update() calls)?

The main issue I am guessing would be the API. If you want to constantly change the transforms of the objects then that might be an issue.

I am guessing something like:



Box box = new Box(…);

InstancedGeometry geom = new InstancedGeometry(“myGeom”, box);

geom.setMaterial(…);

geom.addInstance(new Vector3f(1.0, 1.0, 1.0), new Quaternion());

// etc

Sorry for not responding, I’ve been working on another project.



Do you think there’s a feasible way to efficiently update transformations for interactive animation? Maybe not every redraw but at 30fps or something? It has to be more efficient to send a transformation matrix than an entire geometry. What about building an abstraction on top of the vertex shader to pass in a transformation for each instance id?



If there’s a way to get hardware instancing working it’d make a great terrain demo for the front page and if somebody can help with an efficient way to animate/interact with instanced objects I’d gladly donate a few hundred bucks out of my budget as it’d really help a lot.

Is this perhaps being posted in the wrong forum? I’ve noticed that since the redesign things seem a little slow around here and I’m not sure how the forums were reorganized. Should I be posting in the contributors section or something?



Thanks again,

Ryan

Nope here should be correct, I can already see/imagine really large static astroid fields ingame ^^ this would be perfect for them

The issue is that instancing, to work with jME shaders, requires a special feature called “Shader Injectors”. This is a fairly advanced feature, and so we haven’t gotten around to implementing it yet.

3 Likes

OMG Kirill, I didn’t think you’d go public about this!!!

I thumbed you up big time :D!!

What is shader injectors? Please explain in a new thread! :roll:

erlend_sh said:
What is shader injectors? Please explain in a new thread! :roll:

Nobody knows that, they're an unknown entity to todays science. :P

why do I get the feeling that you’re all pulling my leg… :slight_smile: Is it so wrong to want to kick in cash to a project to further the development of features that might really help one’s use case?

rmnoon said:
why do I get the feeling that you're all pulling my leg... :) Is it so wrong to want to kick in cash to a project to further the development of features that might really help one's use case?

No, sorry, nobody wants to fool you here :) Its true what Kirill says, hes working on this feature and it will allow several things to be done. It basically means you will be able to inject code to any shader that is running.

We certainly appreciate your input and will to contribute but its probably best done by just hitting the forum with a jar file of your implementation or something similar :) We have found that contributions work best in code or patch form than in lengthy conversations over what needs to be done how.. We had lots of those talks but no new core members have come out of that yet, in fact I think not even code ;)

The googlecode project should contain most planned features and by visiting the forums regularly you should also be able to see whats happening and who's doing what.

Cheers,
Normen

Thanks for the clarification, normen. I just wasn’t sure what the hell any of you were talking about. :slight_smile:



I’d love to contribute patches back in, but I haven’t made many and I’m using JME for something somewhat commercial so I’m not even sure that I’m legally allowed to right now. What I CAN contribute is cash to the project if it helps useful things (like hardware instancing) get done faster. Do we have a donation process?



Thanks again,

Ryan

rmnoon said:
(...) Do we have a donation process?
No we don't. Mainly because we got the inevitable server cost covered by @sbook's university / tech lab, which leaves only domain registrations for $10 a pop, so we never bothered to ask for support for that. Lately we've been getting some more ideas on monetary investments though, for instance a 3-in-1 pack of gorgeous WooThemes, or a 3D scene. So yeah, maybe it's time we make the proper arrangements :) In the meantime though, I'd advise against any surprise gifts or any sort; let us think things through first so we can be crystal clear about what would be in the projects best interest.

Right on, I don’t want to corrupt the project with easy money. :slight_smile: JME has been super useful to me and if I can use my budget to help awesome features get done then I’m more than willing to. Hopefully when I get more time I can submit more patches. This community is great!

Dang, I meant to just mention you to get your attention but i forgot, so:

http://hub.jmonkeyengine.org/groups/site-project/forum/topic/figuring-out-a-good-non-profit-donation-process/



By the way, odd replies that sprouted from the shader injection topic were because of an inside joke among the core team. “Shader injection” is sort of Momoko_Fan’s white whale, hi hi.