Completely Real Time Global Illumination Using Light Propagations

Yes, I did warn the scene is expensive and is not optimized. And once again I said it was designed to push the limits and test the system. I can't say for sure why screen resolution affects performance, however I can see how it could slow FPS overall cause pixel shaders are, pixel shaders. There are many huge optimizations that are already possible but just not set up. For example: Diffuse and specular only shaders(which could have potential to double performance), choosing to update GI in increments for day/night cycle, properly mixing dynamic and static probes(every prob is currently either dynamic of static at the same time). These are only some of the current possibilities. The future possibilities are endless.

Keep in mind I am doing all I can to improve performance and visuals. I am only one person and what I am doing is one of the most complex things possible in real time graphics. I'm not going to stop until I feel completely comfortable using this in my own games.

 

I for one am buying your product as soon as you release

Question is it easy to make third party shaders work for it? Any instructions on that would be useful.

Also i noticed performance gets better as u get farther away.. like falling off the edge of the map...as the scene got smaller in view ... perfomrnace just climbed a lot
Im not even talkn a mile away. I mean LODs could have some factor, but it just felt like too big a jump to just be LODs... 100fps to 200 fps..

 

+1

 

+1

I would rather buy early to start playing with it and implementing it, learn how to assing it to other shaders, see issues with my own shaders and all other stuff in my project etc

I have learned through experience with the assets here, that perfecting something can take much longer than actually programming it, so we could help with perfecting this one i guess if a beta was released.

 

Basic camera Frustrum Culling I think.

 

Definently not. Not so sure that scene had any culling going on at all.. and it wasnt view frusttom.. the models were all in view way until they were a dot and i was getting 500 fps. lol...

I mean u get a huge boost in frame rate when the model is at 75 % of the screen covering and ur looking in the direction of everything. More fps then when your standing in the scene stairing at an empty wall with it covering 100% of the screen

 

Not sure what you're experiencing then. I assumed you were talking about facing a wall. Most noticeable if you turn around and face in the direction of the starting room with the fire effects - even when you can't see the fire due to walls, iirc - that moment they would enter the camera's frustrum as I turned caused the biggest drop in frame rate for me. I suppose it could be some other screen space thing or something BG is doing with the fire effects and lighting.

 

What I mean is if you climb the mountain and jump off the map into infinite space and can see the entire world... while the screen is covered u get lower fps, but as the world tkaes up less pixels the fps sky rockets.

 

Nothing is screen based here. This happens with any pixel shader. If there's less pixels to render on screen, performance increases. The fire room is expensive because each brick is pretty much individual. Like I have said many times this scene isn't optimized, it's meant to look pretty.

 

Maybe instead of using 3 32*32*32 textures use one (32*32)(3*32) so that you only have one texture lookup or maybe a 3d clipmap,like the one nvidia described in their vxgi paper

 

Having one, means there is only.. One.. You can make that one as large in scale as you want but you loose clarity to the point where it's unusable, or you have a draw distance and only have GI around the player then everything else is dark looking past that point. Obviously when cascading is done it will be up to the developer which way he wants to do it. but cascading is the only way to have good looking GI for large open environments. It's possible that cascades will be the focus of the next update instead of initial release. For starters I could have the volume fade to a background cubemap for diffuse and specular replacement.

 

What I mean by my post is to basically pack your three textures into one texture, as described here: http://fumufumu.q-games.com/archives/2014_09.php#000934 and for each cascade to cover more of the level as the cascade number goes up.

 

just tested it on a gtx 590... ran at 26 -35 fps but HUGE studder in the real time mode, and static mode was also at 30-40 fps oddly enough and still kinda felt crappy... Anyway to improve the performance further so people with earlier gpus could get in on the action? With a gtx 590 its basically not even playable... the mouse moves and the camera turns 1-2 seconds later. I stay away from all the land marks and fire.. and everything and face the very opposite wall face right on the wall... and those fps are still like that. Away from any structures...

 

I really really wish Unity would pay attention and ugprade the performance of uploading texture changes to the gpu. It has always been a terrible bottleneck compared to doing the exact same thing in other languages/engines. As an example, using BlitzMax - a simple game programming language mostly written in C++ (i think), you can use OpenGL to upload a texture to video ram (to existing texture), using GLTexSubImage2D().... on a fairly old, like 7-year old imac with a 2ghz quad core cpu and ati x1600 gpu (only 2 billion texels/second fill rate), you can upload MULTIPLE 1024x1024 textures at 60hz. Take this same thing into Unity, on the same hardware, I could not get past ONE 512x512 texture, which ran at about 80hz.

There are some major problems here. I would like to be able to mark a texture 'use for streaming' or something, whereby you can just zap a byte array straight to the texture at the maximum possible speed. I think part of the problem is that Unity does some kind of conversion to an internally cached format, before upload, and this really slows things down. It's also not possible to upload only PART of an existing texture, which puts serious constraints on things when you really only need to update a small part of a texture. Many many algorithms could be so profoundly faster. And let's get rid of the horrible SetPixels().... let's just say a) here's my byte array, b) it has this many bytes per row, c) zap that sucker straight to an existing texture. No caching, no keeping a 'readable' version, no internal conversions, just send that data. This would profoundly speed up so many things, even without partial texture updates, which includes a cool system like this GI which needs to update textures every frame. I've been asking this for a few years but I've still yet to see any progress. All I've seen is the addition of SetPixels32() which was an upgrade from the horrendous floating-point-based SetPixels() previously. And Alpha-only textures getting updated only from floating point buffers? What the heck!

 

Haha I could not agree with you more.

 

I meant to say it was a core2 duo not a quad core, and only 1 core was used. But anyway.

I would so love to be able to upload only part of a texture. Major major performance boost for all kinds of streaming stuff, updating large textures with small changes, etc. At the moment we have to split big textures up into lots of small ones, which massively ups the draw calls and hits performance.

 

Could mega texturing help with what you're talking about?

 

Isn't there a spot on unity where people can request a feature and vote for it?

 

Doesn't this help at all?

http://docs.unity3d.com/ScriptReference/Texture.GetNativeTexturePtr.html

 

No because it still has to upload texture data over the graphics bus to the gpu and unity only provides one way to do that which is slow.

 

That might possibly, but it's returning the internal id number of a texture on the gpu, which you have to then use with a plugin, thus unity pro, and someone has to write a plugin to make it useful. But it'd be nice to have a plugin that just zaps the texture data into the texture. Still unity pro, tho.

 

Anyone whose serious about this would be going with unity pro anyway. Unless ur going mobile platform and this isnt mobile... its for serious projects in my eyes

 

People without pro are just as serious - just saying..

 

If you don't have the money to buy pro... your not serious about graphics or releasing a game with strong graphics. Because games like this cost money to make and unity pro is not a lot of money for a product like that.

 

This project maybe, but there are many many other uses for faster texture uploads.

 

Tell that to an indie with 0 or very low budget with medical bills etc who cannot afford $1500 up-front.

 

I'll tell that indie to get a job or use a credit card. Have some balls and invest projects you beleive in... Until then this is a hobby to you so stop holding back the rest of us who have pro and want features tailored for it. Thats what i would tell that indie.

Not to mention that I have medical bills 2400 for chiropractic... and dental bills... 4000 or so for braces.. not counting the root canal i just got... plus im buying a new car right now. Its called investing in your self.. i make money with unity projects so that I could afford these things.

 

This is way off topic. Lets not get into these sort of topics on here. Thanks.

 

Can u make it run faster with unity pro features?

 

It is using pro features. But Unity has not provided any way of modifying textures in real time on the GPU(besides using DX11 compute shaders) so the 3dtexture has to be created on the CPU. I am very sure creating textures and modifying them in CG shader, is possible, but not in Unity.

 

Are u able to make a direct x 11 version to overcome this? Since VR requires 75fps to run proper... chances are my audience will all be dx 11 compatible.

 

I think he mentioned earlier that that's the plan for the future. This technique really does need to be using compute, CPUs just aren't built for rendering and modifying multiple 3d textures.

 

It might possibly be faster to grab the backbuffer into a texture, having made modifications using a shader, than to upload the texture over the graphics bus. e.g. on a system where I could only upload like 512x512 at 80z, on that same system I'm pretty sure it could grab close to 1024x768 or maybe 1024x1024 at 60z. And of course drawing textures with the gpu is much faster, and the shader can do calculations fast. So is it possible to move the calculations into a shader this way, or is that too much?

 

How does BGLight Engine compare to Unity 5.0 GI solution? Will you be using some of those techniques to boost the capabilities of your own Engine?
http://blogs.unity3d.com/2014/09/18/global-illumination-in-unity-5/

 

Will we be able to see more of this?

 

@ haskellf2 I have answered this question a few times. Unitys GI is only partially dynamic, where only the properties within lights can change dynamically(No geometry changes), this is not a limitation with BGGI. BGGI also has completely real time specular reflections. This means real time reflections on all surfaces.

@blueivy I'm not sure what you are specifying. The shadows or being compatible with enlighten?

Here are some brand new screenshots showing the capabilities of a single directional light prob and a few GI lights. This is the scene I have been using for development of the GI. It's a challenging scene to work with but it looks pretty. Might use this as the official demo included.

 

It might look better with the classic SSAO on top of the final render as some floor-wall edges are too clean, further, some floor wall encounters have totally different lighting being the wall totally dark and the floor bright. Some parts of the images look awesome, while others not so much. I wonder why some parts look great, overall the image is not vray kind off in terms of realism. But hey, great work, greatly evolving.

 

Because it's approximated, that's why. Also most of the differences you are seeing is that the floor is reflective and the wall is not. It doesn't look as good as Vray, because it's not Vray.

 

when will this be released

 

Ok BrilliantGames, stop teasing us with some pictures from Unreal Engine 4.

 

The scene looks nice, especially the part in that last image. One thing I think could really liven it up is a better skybox, or out-of-window lighting of some sort, though. Right now it looks way too cloudy to be casting the inside lighting. (the windows are maybe supposed to have a tint, but it still looks too dark outside)

 

I agree, for example the kitchen object looks too emissive. SSAO might help here, but I think that's part of the solution.

 

This GI solution naturally has some AO. It's just limited to what geometry data is available, and in the case of this scene, very little is available(Only the area's where the sunlight hits). Part of the some of the issues you guys are spotting is actually specular reflections with lack of geometry info. For example, you can see the reflections from the sky outside reflecting on the floor through walls and other obstacles because those obstacles are not in the grid. Either way everyone is still used to static cubemap reflections so this is still leaps and bounds better. But yeah the more accurate the reflections, the more probes that are required.

The whole point of this scene is to show how much difference just the sunlight hitting the floor and skylight can make on a scene.

 

Why not use a voxel representation of the scene so geometry data is not limited to how many probes are available?

 

The scene is being represented in voxels(Just no voxel geometry). But you have to get that scene data into the voxels in real time. Which requires virtual cameras.

It's obvious Nvidia is doing this the same way. The lite voxels are a result of a render texture being drawn from the lights perspective. Mine is more flexible where you don't have to draw from the lights perspective if you don't want to.

 

Hi. This looks amazing! In your demos, would it be possible to include a checkbox for disabling GI, to compare performance and graphics with and without GI enabled? If not possible to disable GI at runtime, maybe you could include the demo compiled without GI for comparison? Thanks, and keep up the good work!

 

how did you make the decision to go with probes instead of voxel geometry? Is there any benefits?

 

Did you watch the video I posted? Did you notice the only voxels that exist are the ones visible to the lights point of view? How do you make voxels? You have the generate the data somehow, and the best way to do that is with reflective maps(in other words, a virtual camera that renders color maps from the lights point of view). It's really the only way. It's similar to shadow maps, they are generated with virtual cameras that render with depth maps. I've explained all this many times.

 

I've seen the video many times but thanks for explaining how it works, this is my first time hearing it. I'm curious to see what higher resolutions will look like because things will probably look a lot more jaw dropping. Not to say that it isn't already Also what are the drawbacks to the probes? Can I just go crazy placing them every room?

 

Ya. Sorry about that. I took the time to read all the threads leading up to these posts and noticed you mentioned this a couple of times. Quite an undertaking... Great job!

Three questions:
1) Will the user be able to control the AO, especially if they want to boost it?
2) Is there a feature to add a bloom effect to the bright areas as a post effect? This would really help attain more realism.
3) Can this still be used with Lightmaps to create a hybrid? Would the Lightmaps cause any conflicts? Would the GI recolonize the Lightmaps in its solve?
Ya, I know that some would say that you won't need them after using your system, but sometimes Lightmaps look pretty darn good and can help solidify the realistic atmosphere of a game especially when used with dynamic and some static GI.