Graphics HXGI Realtime Dynamic GI

Dynamic objects are lit by the irradiance volumes that get calculated. Voxelized objects also get lit the same way. Its just that voxelized objects can contribute to the GI calculation.

It depends on how complex the part of the scene is changing. Somewhere between 0.5-2ms on a 660GTX to revoxelize a chunk. Chunk size should be (64 * voxel scale)^3, I might attually store them in smaller chunks though, That way if a smaller area changes it doesn't have to revoxelize such a large area.

 

So after making some more ground on the new method for generating the GI data, it looks like it would need to do a pre-compute step or limit the GI to a cornell box. I was trying to do radiance caching at runtime by rendering X number of new sample points each frame. Basically the way it works is for every face in the world you render out the scene as a hemisphere to capture the incoming lighting. Normally that would be impossible to do at runtime as it normally takes 3-16ms just to render the scene once.

So i was working on an idea to use the voxel data to render the scene out in a single draw call from the view of 1024 different points per frame. Worked great on small detailed scenes. My plan to tackle larger scenes was to make it render out a bunch of cube maps of the scenes from key locations, then each point would only render near voxels and fill the rest from the interpolated cubemaps data. This would keep the overall triangle count pretty small.

Doing all of this in 1 draw call costs 40ms to render out this scene from 1024 different view position (0.039ms per view). If i was to only render nearby data i can get it down to around 2-3ms, But generating those cubemaps for interpolation would still cost a lot. I could render out less per frame as well, but id need 12000ish samples to generate 1 bounce...

The cool thing about this is you get really good skybox lighting for free and indirect shadows would look amazing, It also supports specular as well. I've found a few research papers and the fastest I've seen is something like 1 second per frame... I think this method of rendering all in 1 draw call would significantly speed up the process, but not in the order of magnitude i need.

In the end i think I'll just switch back to light propagation for generating the GI, The old method stored the GI using 4 coefficients, If I use a sparse irradiance volume instead, i should have enough VRAM to use 9 coefficients. That should improve the indirect shadows at least.

Something interesting about storing the faces rather then voxels is it should support thin wall a lot better now.
This should improve a bunch of the issues i had with the old method as well as making it more stable.

Below is an example of what the radiance hemispheres looked like. These would be mipmaped down to quickly sum all incoming light for a face. The texture would be cleared with the skybox cubemap so any empty pixels would instead contain skybox data. MSAA worked wonders on this. I think i could get away with rendering each as 32x32, But fill rate wasn't really an issue. it was more the amount of triangles i was rendering.

Overall a really interesting take on GI, Been interesting reading about it. Might be able to use this in some capacity down the line.



For testing purposes they all used the view matrix of the camera rather then each face. Purpose was benchmarks.

 

"Basically the way it works is for every face in the world you render out the scene as a hemisphere to capture the incoming lighting."

Lol I love that this is actually a thing people try. Render the scene once per face. That is very lol-worthy. 40ms is very impressive for rendering the scene 1024 times haha. Brilliant. I'm imagining being in a fragment shader, and looping 1024 times, changing the camera matrix each time and writing to different parts of the texture. Probably way off, but super fascinating idea.

 

Little off, Its just a bunch of quads, So you render using DrawProceduralIndirect and calculate the matrix in the vertex shader. Then have all the data loaded into some buffers. I actually use a geometry shader and render the scene as points, That might be slower though, Will try switching to quads. A lot of games use this type of tech for light baking, the witness used it for example.

 

I assume that this only needs to be done once each time that area is dirty (IE some static geom changed)? If so, 40ms is perfectly fine as that can be done in a loading step away from active player input. From that point onward you would only update dirty areas of the map.

 

Correct, it would need a pre-compute step just like enlighten. it would also make dynamic changes other then lighting pretty hard to do. If something in a chunk changed you'd have to revoxelize that area, then render out all the face data before replacing the data in the voxel grid.

40ms for 1024 face sounds pretty fast, but for this small room I would need 12000 points and you'd need to render them all once. That's 4.6 seconds just for a room.
I've looked into different grouping methods to cutdown the number of sample points. But i don't think its possible to get it as low as i need while still retaining the detail I want.

 

So again, I'd like to voice my suggestion to not market towards the Unity Asset Store, but rather go with your own website and licensing solution. We don't have an active VR project right now, but let me tell you 100$ is a drop in the bucket for what we did. Eyebrows wouldn't even be lifted for 500$ and 1000$ would also not be difficult decision.

 

Ouch. These numbers would outprice the vast majority though.

 

I am okay with $500, as long as it delivers what it promised.

 

yeah, let's be realistic though...

 

Lexie seems quite capable of delivering, but keep in mind nothing has been promised.

 

Unity is aimed more to indi-devs. The few triple AAA´s can build their own Gi-Solution. From a Business-perspective it doesn´t make sense to sell a asset at $500 ! (indis = less money ... triple AAA´s can build their own stuff). Question is, does he sell more copies if he aim indi´s or if he aim triple AAA´s ? Its clear, that you have to aim indi´s, if you want sell more copies. Simply look at the asset-store ;-) ... i doubt that many unity-user would buy a $500 asset ! As you can see the biggest range is something with 60 -100 $ that many users can afford.

 

I agree I wouldn't buy anything on the asset store over $150 maybe $200 and it would have to be flawless.
From what I've noticed you can make two versions one that's cheap with no source code and one more costly with code, that should help with piracy as well.

 

I don't think anything like that really helps with piracy. Most of the assets I know that had 'no source code' cheaper versions gave up on that strategy, but this comment is based on a very small sample size. In my opinion the best approach to piracy is to try not to let it bother you, because I don't think its an area where much can be done and its only a big issue if you imagine all those pirated copies should have been real sales, or if cheeky pirates ask for support (which many asset store devs deal with by requiring invoice/order number).

Rather I think that the burden of support, and expectations about how much money people hope/need/expect to earn, are the big issues where there may be room to do something. I wish Unity were more flexible about support, because the demands of supporting assets often eventually leaves me with even less support, because in the end the asset authors just burn out and stop development of their assets completely. And I never see Unity joining in this conversation, even when increased number of platforms, increased frequency of breaking changes in unity release cycles, etc, arguably increased the burden. This leaves me depressed, with a feeling that the situation is just getting worse as the years go by, and as a result I buy far less assets than I used to.

 

The issue here is that Lexie wants to provide a solid product to the community, but I am sure based on the past results he has had with selling an asset, he is wary of going down the same path. As elbows has stated I have bought many assets that ended up being useless because of creator burnout. The problem just as he said, caused because the creator has to not only continue handling development based on their road map of features, but the many other features their customers ask for. There's also the bugs they uncover, the constant battle of keeping the asset up to date with Unity's ever changing landscape and the future versions to come, all while keeping the asset compatible with the past versions as much as possible. Sometimes the asset needs to be split into two or more versions due to this. Also we haven't even factored in their own personal projects and or normal work. It quickly becomes an impossible task for small groups of people let alone one developer to handle.

In truth, the asset will benefit greatly from having 5 customers who spent $1000 each vs 50 who spend $100 each. Those 5 customers will be of a different breed, ones who not only can afford the cost but also usually have greater experience and less needs from the developer. The developer then only needs to worry about 5 people, who will receive better attention for their issues all while having 45 less people to worry about, increasing time for development and lowering support substantially. (Also a bit more money can be saved by dealing with purchases privately)

This is very similar to the Steam Direct debate going on a few months back. Tesla dealt with the problem in a similar light, they came out with a great car that was out of the price range of the average customer. By doing this, they could put their all into the car all while supporting very few. There are many cars in the world to buy, and all get you from point A to point B. Sure it is nice to have self driving features, a battery driven electric power-train and doors that open like a falcon spreads its wings. Sometimes we just have to make due with that Honda until we are actually able to get the Model X ... or wait for a Model 3. (take note of all the issues they are having with their first ever massed produced economy class vehicle)

 

Assuming it is 5 vs 50 sales, this would indeed be best case scenario.

But in practice it depends on many factors and the exposure the more sales bring, and that ratio can be anything. Having less sales brings the asset lower in the store ranking and removes a lot of exposure, lowering sales further for example. So essentially a very expensive asset may go so back that noone will know about it eventually, leading to almost no sales in the long term.

My suggestion is having a logical price for the environment the asset is sold in. I would go for $150-$199 for something that is truly extremely special and unique, but not more.

This price range imo will also bring the above mentioned effect of selective customers and less need for support to a good degree.

 

Or do what a lot of software companies do: offer tech support for those with a more expensive lisence and let the community help itself for those with a standard lisence. If you've got an awesome product that's popular the community will rally around and help each other out a lot too. And then when you've made some good profits but the support is no longer worth it, open source it like segi did haha.

 

I don't think Unity allow that, you have to offer support. Which is why I complained that I never see Unity joining in these sorts of conversations, although to be fair since I am not a publisher of assets myself, I am not privy to all the discussion that happens there.

 

That's the problem, though. Lexie wants to see how many people are interested in this Asset. I don't think that most of us could afford buying this for whopping $1000. Imagine he would go your route and really has only 5 customers in the end: yet another Asset from him that attracted less customers as initially wished - and that's something he worries about. The best range imo would be something around $100-$200, but higher than that... no thanks.

Either way, a decision must be made and sometimes you have to sacrifice a lot... It's just the question what's better in the end.

 

Most devs will probably go the route of selling their Assets through their own website. As you're not "soulbound" to the Asset Store, you can sell your Assets on sites like itch.io, gumroad, etc just fine. However, the price must be the same on all platforms.

 

Im currently at twitch con working on that contract work i talked about earlyier. We were contracted by twitch to make an AR game thats played through the stream using the new twitch extensions so users can interact with the stream.

Users get income to spawn ships and every time their ship gets a kill they get some extra income.

Here is a video of it running. https://go.twitch.tv/videos/183714723?t=51m33s

There is an overlay that displays buttons to spawn ships + mini map with the location of all the users ships.
All the gameplay is calculated on the GPU using compute shaders so we can handle simulating that many ships.

The CPU only plays sounds and handles all the networking.

Ill get back to working on GI soon. Will need a little rest after this ends though.

 

Oh hey that's a very cool idea! Now we see where that 'gameplay on the GPU' work went into! It looks like a huge success to me. Congrats .

 

I would gladly pay 100-200 dollars for a working realtime GI solution - looking forward to seeing where this goes!

 

Looks great!

 

Is your approach similar to the one described in this research paper? @Lexie

 

No. I was reading through this paper this morning. Pretty cool idea. My method is based more on an older style of GI called Light Propagation Volumes. But I'm currently exploring other methods to see what is going to work best for my game.

This paper still needed a really long pre-compute pass (1 hours for those test scenes) So its not ideal for procedural content.

 

@Lexie got any good resources on where you learnt about LPV? The material on spherical harmonics I've found is not easy to follow. I understand in concept the usefulness of mapping 3d directions to 2d functions but in terms of guidance on practical application it's hard to find good info that doesn't require a bloody maths degree lol.

 

X-posting something I shared on the SEGI thread because it's relevant

 

Thanks heaps, I saw this presentation a few months ago, nice to have an article to look back on.

 

hi, Lexie , where to get your "HXGI", it seems cant be found on assetstore.

 

its not for sale or publicly available

 

oh, it is a bad news, did you use SEGI before?

 

you can use it for free now. https://github.com/sonicether/SEGI

 

Tried SEGI just now and it had lots of flicker. I couldn't find a setting that would fix that.

 

I'm really looking forward to this. SEGI, while open source, does not seem to take scene sky-lighting into consideration, which is a huge let down to be honest.

 

same here, make it part of the game story: you're in glitchy matrix

 

Jokes aside, I seriously thought about using it as a grain effect.

 

Until the grain starts looking like flickering polygons in mid-air, this just happened. I'll just dye everything green and add cats.

 

Hm only flickering I've ever had with SEGI is due to a recent bug if image effects are enabled in the scene view whilst the game view is open, then you get some strange artefacts, so I just disable scene view image effects. Other than that its flicker free.

 

GOTY!

 

I turned off scene view fx and the weird glitches are gone. Green off, cats off.

 

Doh!

 

@Lexie How's development going? I always enjoy reading your posts describing your experiments - it's like a dev blog.

 

GI solution from Brilliant Games Studio

 

Woot! Amazing stuff there.

 

As good as it looks, we won't see it in the Asset Store. The developer of it made it pretty clear in the past that this tech will be only used for their in-house game titles. It's nothing new, either, as videos of this have been posted years ago (example).

 

Yes, there is also this which is also years old, SpectraGI:

No need to further pollute this thread with other GI solutions that will never be publicly available.

My fingers are still crossed that HXGI will become available in one way or another.

 

Ah, I see, thanks for pointing that out. Yeah that makes HXGI seems more desirable, too. Honestly, the Brilliant Games GI doesn't look that astonishing, but it is realtime.

 

I tested this room configuration and SEGI doesn't do so well. There might be settings that work in a closed room but after half an hour I haven't found them.

 

Maybe the pot calling the kettle black, but you should probably post this on the SEGI forum...