Ah, that’s too bad. I noticed I can downplay the via the usual route of boxing the geometry, but then things take a weird turn with VXGI flickering on and off depending on the camera angle.
Even so, VXGI is a very promising and exciting technology.
Not yet, but I know where everything has to go now, I spent a lot of time trying to figure out the rendering of particles in UE4, and went a little over the top by creating my own type data for flex fluid, until I realised I only need to change the rendering.
Actually writing the shaders required is relatively easy, same with scene proxies and vertex factories, the way particle rendering is structured is fairly complex looking tho. Will hopefully have something to show today or tomorrow, if all goes well.
Maybe an option could be to use the collision object instead of the main object, if the user so chooses. Could be an option per object. way u could build a low poly hull used for collision and for voxelization all in one.
Uh, anybody kind enough to shed some light on ?
I’m kinda stuck trying to figure out how to implement game-play given the lack of data feedback from the simulation…
1)Is Substance supposed to work with ?
The plugin gives me an error that it’s not the correct version of the engine…
2)Reading the .pdf it states the GI should be near flickerfree but when I try to matinee a directional light over a timespan of 15 seconds (going through 45 degrees of the light rotation) I see a lot of flickering.
Low settings, high settings, insane settings, the flickering remains. The scene is average in complexity. Not a simple box but some 50 meter corridors with pilars, couple of cloth banners, couple of speedtrees.
Can anyone confirm/deny/comment on whether dominant lights are supposed to be moveable with VXGI?
I also animated a glowing ball and that went flicker-free even though the transition between the voxel iterations/clipmaps is quite crude (no smooth flow of the emissive light coming from a distance through a long hallway towards the camera).
I’m guessing is similar to the light-leaking described a few posts up and currently there’s no easy fix. If so no prob, it’s still tech 
Aaaah!!
Thanks 
I could be wrong, I’ll have to check, but given a fixed number of cones, I think that narrower cones should require less processing overall because a narrow cone encounters less geometry, and covers fewer pixels in screen space. If you are trying to cover absolutely everything with cones, a few big cones are probably faster than many small cones.
Hi there ,
I’d appreciate it massively if you could you shed some light on these burning questions on my mind
Cheers!
Workshop Foundry
Its coming, after I convert HBAO+ and do a VXGI + Flex + HBAO+ merge. Then I will do a VXGI + WaveWorks + HBAO+ (If they all work together) merge. If NVIDIA doesn’t beat me to releasing their 4.7 stuff 
That’s a clever way of doing it.
Sure, sorry for the suspense. As you note, the FleX API offers many things that are not yet exposed through UE4’s blueprints, or through any other mechanism. In time we will be adding support for particle state readback, etc, but they aren’t the top priority at point. Surface fluid rendering is still under way. FleX will never support the full range of gameplay hooks that rigid bodies do, such as contact callbacks, custom constraints, etc., but it may be possible to expose constraint forces in some way. I’ll pass the request along to the and see what they say. Every data synch back to the CPU is costly, so we have to be careful that new features will not degrade performance beyond usefulness.
3D volumetric objects are possible, I suppose we just haven’t exposed that at the authoring level yet. A destruction based on FleX sounds like an interesting idea to me, but our experience with rigid body destruction indicates that it will be a lot of work.
–
Does anybody know of a console variable to disable reflection probes? The current VXGI Specular implementation doesn’t seem to do automatically.
Serious Question: What exactly is the purpose of having HBAO+ and VXGI in a single build? Based on what I know of the technologies, VXGI has AO, and according to the slides that posted earlier, it’s more costly than HBAO+, but MUCH higher quality, and still runs on low end well. I understand that there is a gap between SSAO and VXGIAO, but is that gap really big enough to be worth supporting HBAO+ alongside the other solutions? I’m just not sure if it fits.
One reason we pushed out these features originally as individual branches is that it’s not completely clear that they will all be used concurrently in any single application, and it is easier to combine desired branches than to separate undesired the features from a single combined branch. For VXGI and HBAO+, suppose for the sake of argument that a user found that VXGI added a lot of value to an interior scene with dynamic lights, but was somehow not the best choice for a large outdoor scene; and HBAO+ worked great for that large outdoor scene. In that case having the two features in one branch makes sense. Again, I’m not claiming that is the case, it was only a hypothetical explanation; and I think the user community will guide us through experimentation.
Update: I updated the FleX, WaveWorks and HBAO+ branches of /NvPhysX/UnrealEngine to 4.7.3 (along with the release branch, which is straight-vanilla UE4 release). The VXGI team is taking a look at the 4.7 update, apparently there is some subtlety to it, and they are combining effort with some other recent fixes and improvements that address some of the issues discovered by users; hopefully we’ll have a VXGI update next week some time. I’m turning my attention now to problem where WaveWorks and FleX refuse to play nicely with the GPU resources.
Many thanks to for his efforts on the 4.7 upgrade, there were some changes in UE that confused me and after studying his fixes I just merged them as they were. Much appreciated, sir!
Sorry if has been discussed earlier, but how should we set reflective surfaces with VXGI? Enabling emissive gives a pretty nice result other than the obvious light bleed on to other surfaces:
://i.imgur/glo4lNOl.png
Otherwise I’m getting very impressive results now that I’ve had some time to mess with the parameters.
At the moment VXGI Specular only uses direct light to create reflections. That being said, having most surfaces in your scene covered in direct light is required to get proper reflections. Some scenes may not even need special changes, but most of the time, you will need to adapt your work flow slightly. Setting emissive to a value between 0 and 0.1 is very effective on metallic surfaces in particular, as it completely removes “empty” reflections by adding directly to the base color. In scenes that don’t require heavily controlled lighting, you can use dim ambient point lights set to movable, which is probably the ideal setup for games that don’t using any static lighting, because it causes low end devices that can’t support VXGI gain some ambientnce as well. These are just a few suggestions based on my own tests; play with it a little and please, report any findings you make! 
Hi ,
Thanks for the insights!
Glad to hear that 3D objects are being considered
Regarding fracturable Flex solids, it’d be a real pity if the deformation works so realistically, only to stop short of breaking? (perhaps Pixelux’s DMM engine will serve as an inspiration :p)
Speaking of simulation data feedback, I really hope the will consider as many avenues of feedback from the simulation as possible, since meaningful interactive game-play cannot be built in any practical way without mechanism.
I can imagine so many use cases already:
- generating scratching sounds/sparks depending on the amount of friction between 2 solids rubbing against each other
- knowing if sufficient quantity of fluid has pooled up in some container to trigger some game event
- setting off an explosion the moment gasoline particles come into contact with some hot surface
- the list goes on etc etc
Without feedback mechanism, I cannot imagine not being able to do any of these things which I’d adopted Flex precisely to accomplish.
I’d argue that all possible kinds of simulation data should really be exposed from the onset, and the developer should at the very least be given the choice of what simulation data to “enable”(in the process cognizant of the respective CPU cost) while “disabling” the rest.
If you ask me, I really want to believe that Flex was built for much more in mind than mere “window dressing” …:rolleyes:
Cheers!
.
Thank you so much for the 4.7.3 FleX update. Downloading now.
Blakblt
Ah, so no golden ticket either. Thanks for info, I’ll play some more and post my findings