Hardware instancing patch... please can we get it in 1.8.0??

[Granyte]

http://www.mediafire.com/?qv441dv4anp2jjo

Link to the .patch file this file should add instancing for both dx9 and opengl it should also add the instancing example







here it's real instancing for dx9 running over 5000 instance individualy animated.

[hybrid]

That sounds really good, I will have a look at this once 1.8 is out. Thanks so far.

[devsh]

I have already made a "patch" for tessellation shaders so look at that with your Dx11 driver

I got 3D textures into irrlicht, ITexture should have a new function called "bool is3D()"

Then derive a COpenGL3DTexture from COpenGLTexture so you can modify COpenGLDriver::setActiveTexture(stage,texture) easily for glEnable and glBindTexture

I'm still a long way off, I first need to implement a C++ implementation of this for static scenes
http://www.youtube.com/watch?v=fAsg_xNzhcQ

then I'll port this to compute and VRAM for the specular reflections

[Granyte]

tesselation will be implemented in dx11 but the driver is stiill in the work and i don't have dx11 hardware to test it

could you post your patch for 3d texture in openGL i will implement a dx9 and dx11 version

and where is your tesellation patch?



EDIT i put a small update to the patch to deal with vertex2tcoord and vertextangents as befor the behavior was undefined

ill upload an updated patc if the general way this one works is good enough

[hendu]

@devsh

I think building on my array texture patch would be cleaner, wrt the is3d method. I prefer the gettexturetype way, as there are more types than just 2d and 3d. Like 2d array textures

@hybrid

Please no fake/shader instancing. Real geometry instancing only.

The difference in VRAM use between those two is huge. The fake way has the geometry there multiple times. Since DX9-class cards support proper instancing in hw, there's no reason to use a worse method on capable hw.

[Granyte]

try the patch both are suported in dx9 real hardware instancing and shader batching

The only real thing in my patch that is not the "by the book" way of doing instancing is that there is no way with irrlicht to send all the matrices with the vertex as the interphase does not suport it so i hack the 3rd texcoord and use it to send an instance ID wich is used to find the instance matrix and data.

and if my vertex texture patch ever gets accepted some one could pack as many array as he wishes in a texture. and draw batches of 1024 or 2048 instances

[hendu]

I have no Windows in the house...

[Granyte]

then you can still try it to use the openGL version wich is included in my patch

even the dx11 driver already suport it i just need to figure out how to send array of matrix in it as it's currenty bugged


EDIT: fixed the dx11 driver suport will suport instancing based on this patch out of the box

[hendu]

Quick review of the mediafire link above:

- includes many unnecessary files, VS temp files, logs
- code style is inconsistent with itself
- a lot of copy-paste, would be better to consolidate functions (common parts)
- mediafire is a bad host, it took four tries before I could download the patch

[Granyte]

My bad for packaging the log files

as for the coding style i'm un sure about how to keep it consistend even less with irrlicht so it's fairly possible that it will need some one with more experience to take a look or you could tell me what should change

there again i'm unsure about the openGL version as i only copied the code on the first ppage but in DX i could not really walk around it and doing it this way also leave the rest of the appi Intact only adding new function i though it would give me more chances to get it integrated then if i just started messing around with the existing one

[Nadro]

This looks really interesting. I know that FVF was planned for 2.0, but maybe we should add it to v1.9. It will be helpful for instancing and for custom shaders. I think that in v1.9 we should add following things: OGL ES (with Android an iOS support - iOS is nearly done, today I'll add retina displays support) + FVF + instancing + shader based shadow volumes + 3d textures (many of this things already exist, so we are in good position). In my view v2.0 should be dedicated for D3D10/11 and OGL3/4 drivers with support for tessellation and texture arrays. And we can't forget about compressed textures. We should add this as soon as possible.

[devsh]

2.0 also needs compute shaders, UAVs all the different crazy buffers for shaders and feedback transform

Also the GL driver should give handles to textures and buffer objects

[Nadro]

At 99% we will not add a support for compute shaders in v2.0, because we a try to decrease a release time as much as possible. I think that we'll add it in v2.1. But UBO, Transform Feedback and others OGL3 stuff will be part of OGL3 driver, so it will be part of v2.0.

[Granyte]

if this patch is evaluated for integration with irrlicht will it be befor or after the FVF?

because ethier way this will need a redesing when the FVF will be integrated.

and with the FVF we could use instancing in dx9 with the per instance vertex component to store matrix or w/e else the user wishes.

how ever i have no idea if openGL can handle per instance vertex components if so how does it work is it similar to dx?

[Nadro]

I think that FVF should be one of the first change in v1.9. It will be allow us to increase testing time of FVF (during all 1.9 development time) and implement features like an instancing even better and easier.

What about instancing in OGL? Hardware istancing is available by extensions in OGL2.x and it require OGL3.x capable hardware. Of course we can use pseudo instancing, but this isn't good option I think (performance of it is really low compare to native version).