NVIDIA GameWorks Integration

Well I think the reason is that is what I would call a “0+1 bounce” approach:
The voxel data structure that holds the lighting information contains only samples from directly lit or emissive surfaces (0 bounces),
and the 1 bounce is achieved by the cone tracing into the voxel structure when shading surfaces - which gives us one very nice diffuse bounce.

But for reflections, means that reflective surfaces are only able to reflect that 0-bounce lighting stored in the voxel structure.

For reflections to be able to reflect the 1 diffuse bounce, reflective surfaces would either need to perform 2 bounces themselves
(first, trace a number of cones to surfaces that surface “sees”,
then trace from those surfaces into the scene to determine their illumination so we can reflect them),
or like someone else said, the 1 bounce diffuse illumination calculated for the scene would have to be added to the voxel structure after diffuse shading, and the specular shading performed afterwards - that way it could “see” and reflect diffuse bounce.

The first option sounds expensive, duplicating a lot of cone tracing that was already done for the diffuse shading for the reflections.
As for the second option, separating diffuse and specular shading into different passes is probably going to be expensive as well…

Well, I hope you guys can come up with something :slight_smile:

Yeah, worked. It was what I suspected going through the thread.

Thanks.

That’s quite strange. When I looked into I easily increased the particle count to over 50,000 using a 680. I’ll have another look when I get a .

We’ll be sharing some more advanced sample content in the coming weeks. I am pretty sure functionality is already being addressed, but I will inquire to learn more details.

Flameworks is being folded into Turbulence. We already have the fuel and temperature terms from the Flameworks prototype merged into the Turbulence v1.3.3, but the volume rendering is still work in progress.

And when is public turbulence planned?

@: Do you have any info on the spec model used by HairWorks? If not, would it be possible for you to obtain that info? Thanks!

I’ll ask for details. The UE4-HW integration is coming along, but I haven’t looked at it closely myself yet. I’ll try to get some information and post it ASAP.

Thanks,

Turbulence is part of the APEX SDK package. We should have the APEX-1.3.3 SDKs available within two weeks; we already have a Turbulence integration into UE4, but it will need to be updated and I don’t think we’ll see that until later in March. Also, the volume rendering is a separate, so it will take longer yet to implement the volume rendering. However if you think you would want to try to implement your own renderer on top of Turbulence, I’ll see what I can do to publish the updated Turbulence integration sooner rather than later.

Is on your ToDo list? May I ask when the 4.7 integration might be completed? I really enjoy using the 4.7 branch and don’t want to go back.
4.7 + VXGI (+ FleX) = Win

Yes, it’s on my to-do list, but I don’t think I’ll get to it until 4.7 is fully released.

Yes, I agree that cone tracing is the most expensive part of vxgi (in fact, voxelization has miniscule cost compared to ). But for additional bounces, you can use less cones because the details are less noticeable:

For diffuse, 5 cones (1 normal, plus 4 in each tangent direction to a surface) would be sufficient and you only need a single cone trace for specular. In fact, for the first bounce, I’m pretty sure they only use a single specular cone which is treated as a ray in the direction of the reflection vector.

I have done in practice in my own experimental engine and it only at most doubles the cost of the cone tracing - was able to give me unlimited bounces. In fact, you can test the cost of these additional cones by adjusting the number of cones in the vxgi diffuse parameters.

I would be able to do in vxgi to demonstrate, but they need to provide some instruction that allows data to be read from the 3D texture, something like VXGI::LoadVoxelizationData (which currently doesn’t exist).

Yes, the point light is movable. I figured out the bug. Its because point light shadows are dealt with separately - they all fall under the OnePassPointLightShadowProjection functions.
I tried to direct the pointlight shadow cubemap into the voxelization shader, but can’t seem to get any results from the cubemap.

I downloaded and compiled with no error. Only one warnings which is rename something like that. But when i try to start it says “initializing…” then my computer slows down and freezes. I waited like 1 hours and nothing happens… Any ideas? I have i7 - 4770, 16gb of ram, nvidia GTX 780.

Yes, is the same problem mentioned above, you have to rebuild the ShaderCompileWorker. There’s a bug in the UE4 solution, there should be a dependency that forces a recompile.

Oh thank you very much.

Maybe the points about ShaderCompileWorker and nvapi should be in the README, at the moment it just seems to be generic boilerplate.

By the way. I can use commercially right?

are some results from testing emissive lighting:

I have noticed that if the emissive part of a texture is too small, its color will not be included in the voxelization:

Also with emissive textures like the one I used, there isn’t a smooth transition when you move further away from the object due to .

I understand that there must be a threshold where the emissive part of a texture will not be included in the voxelization if it is too small - for optimization purposes. Is the vxgi voxelization thickness parameter? Doesn’t seem to do anything when I adjust it.

I found a workaround for : I used my own texture, which is less clean than the one found in the starter content. i.e. since there is more “color” in it (even something that is close to black but not zero), it gets included in the voxelization.

Btw, how is filtering of the voxels done? Is it completely handled by the hardware mip map interpolation or is additional blurring done using a compute shader?

Just noticed something, it is 16300 per emmiter, so I’m pretty sure it has to do with some config variables of memory per emmiter.

EDIT: With multiple emmiters I can get as many fluid particles as I set in the container.