Handling 3d assets in a larger project

for a 2 minutes vr ride-type experience (read 90fps), meshes and shading seem to fill up the gpu load quickly
looking for tips regarding efficiently handling this resources

  • asset management - can it be done on the fly with any tool?
  • combining pbr with discrete shaders (hbao, reflection, bump-glossed, volumetric lights, xray etc)
  • instancing: are there non-noodles shaders that support it ?
    ::: other ideas welcome ::

batching and instancing basically.

As for batching, vvvv doesnt have native support for that, but you could do it already in your asset pipeline with external tools, basically combining geometry and write material Ids as vertex attributes, to save draw calls.

And for many objects with the same model instancing.

And for instancing, you just need the instancer node and use it in the shader, there is plenty example around.

And engine wise, a deffered engine helps a lot in larger scenes. Here the forward shaders quickly make problems if you dont do frustrum culling and visibility culling, and at least occlusion culling with visibility buffer for batched scenes is not publicly available in vvvv. But it can be done with DispatchIndirect and a ComputeShader that culls according to a screenspace visibility buffer (also would benefit from hierachical z for speed up).

I am working on these things but I am slow with it a bit.

Regarding your question if model loading can be made dynamically.
Usually with todays high end graphic cards you can also load very large scenes at init time. You realy just need to take care for a good culling and draw call management then it should be no problem.

@batching: are there vvvv shaders that support it ?

@instancing: could you point to an instancing code that could be used i.e. for the xray shader ?

@deferred: i see a supershysical deferred branch is underway

@culling: would it still make sense to think about culling in a deferred scenario like the upcoming superphysical? can it be a modular part usable in patching ?

@ggml: I plan to release a (nearly) “complete” pbr engine this month (instancing included). Considering culling it will feature a tiled deferred approach as it’s still the standard way to render a huge amount of lights at a quite low cost. I impemented the method described here: https://software.intel.com/en-us/articles/deferred-rendering-for-current-and-future-rendering-pipelines

Additionally it will feature GGX area lights (sphere, textured quad, tubes and discs) and dynamic reflections from light probes (with filtered importance sampling). How urgent would you need this?


@flux wow awesome, I am looking forward for that day since four years :D
best engine ever.

@ggml: instancing there is a lot of examples in the DX11 girlpower.

For batching is nothing out there as far as I know. But it could be done with vvvv.
For example if you have 10 meshes with different textures, you could batch them by writing all vertex attributes into one mesh and in addition you would write an ID attribute.
Then you can use this batched mesh in a shader in which you can pass a texture atlas that contains your individual textures and look them up for each batch element based on the ID.

culling helps especially if you have realy high poly count or a lot of particles with much overdraw. helps also in deffered but is less crucial.

@flux thanks for juming in, may i email you regarding project specifics ?

@ggml: Of course!
@tekcor: Well, how time flies… ;)

how would depth pre-pass work with SuperPhysical ?
needs to be coded inside the shader ?
[solved: depthprepass needs to be grouped beforehand the actual layer output]

why is the attached example rendering better performance in non-instanced than in instanced mode ?
instancing question.zip (66.1 KB)

maybe try normal instancing in the vertex shader without the geometry shader approach of Instance Noodles.

Just see the example of Instancer node, its actually just about writing the buffer in the shader and reading it with instance id, which is automatically assigned by the instancer node.

So many people here think Instance Noodles = Instancing , but often it is not neccessary to use this (fantastic) lib

oh no :(
so no transformbuffers ?

you can still use transform buffers.

but if the render engine has no buffer input, can i do without readback ?

i encourage you to open the shaders in that case :) see other thread:

This is essential knowledge, dont miss it otherwise you will be always relying on what others put out there and that only because of missing out how to add four lines of code

1 Like

Someone interested in doing a sponsored implementation of DynamicBuffer Transform input for the new instanced deferred/forward superphysical ?
Goal is to be able to support noodles operations as the one in attachments instancing.zip (463.3 KB)
@tekcor described the implementation

@ggml it’s already there afaik in the repo you link to

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.