SEGI (Fully Dynamic Global Illumination)

Sorry but I do not think this is the best idea. For SEGI at least. Could give Sonic a good job though. It seems like whenever Unity picks up a dev their incredible asset dies and is never(actually) worked on by Unity. Unless it is 2D nowadays decent out of the box additions to Unity are not too common and take a very long time to be completed. Also find it extremely unlikely the Unity team would be interested in incorporating a more hardware expensive tool into Unity. Even if it is 10 times better than its current tools.

Personally I feel Sonic teaming up with one or two other code nuts would be able to complete a lot more and also have it working a lot better than the Unity team would. Also would not get buried in a promise for the next release hole. This is a big enough Asset and is in so mcuh demand than most other things that I think it would benefit Sonic to get help with it and once things are done and it is past beta put a decent price that would make it worth the extra man power. I mean decent lighting in Unity is the holy grail for many devs. Get some performance and compatibility gains in here and there will be a lot of support. A lot!

 

@Baldinoboy Just curious, what assets in the past did Unity buy, but then become abandoned?

 

It would be cool if Unity picked this up. I wonder if they would? I think Octane renderer is coming in Unity 6 (I have no idea)? But its a cinematic quality renderer, not really ideal for real time.

SEGI is amazing though and I cant imagine going back to enlighten now. Teaming up with some other coders seems to me would be the best idea? I fear open sourcing would fragment and with no $ motivating development it could just fizzle out. But who knows?

 

There were a couple but I can only remember Strumpy Shader Editor, which is now open source but Unity brought the dev on and the project kind of faded. It is still getting updates I think but nothing profound. There was talk of making a material editor built in for Unity like UE4 but that did not happen. There is another but I can not remember what it was.

 

Also it will depend on whatever he does with voxelization where most of the computation is spend (ie why cascade is key). Apparently it works more than perfectly once the voxelization is done. Injecting premade voxel, having a different pass or handling voxelization differently is key to performance, we already have runtime GI if we "remove" that voxel hurdle.

I wonder if he shouldn't separate the two and let us feed whatever optimization we can build to extand or adapt to specifics of our project (voxel/gridbase world are inherently already in a good format as an example, so doubly voxelizing is redundant).

I think if he open a part, voxelization should be it, then he keep authorship on the juicy valuable part.

 

From what I've read, OTOY's Brigade renderer is designed for realtime GI in games. No clue whether it's in the cards for Unity, though.

 

My "2 cents" recommendations:
- Update 0.83 to next version (cascades + work in Scene view + fix for autoMipGen issue + bluenoise).
- Re-think and improve your creative workflow. This task is not that can be solved via pure inspiration & fun (like SEUS!), there is too many experiments to do and fail before robust solution blooms on horizon; prepare for at leas a half year of this. Search for a rythm of experimental work where you will not burn out on failed test (e.g. if you start to feel exhaust - stop experiment, don't overbear frustration - drop the task until inspiration comes again in next month-two-three). Even in Crytek's that SVOTI stuff took more than 2 years to be shaped in current state (still "Experimental feature" that need to be manually switched on).

Time to level up ) - this kind of task is a challenge for you as coder/creative thinking person and requires special approach.

P.S. And search for the ways to make that kind of project simple & fun again XD. (Sine Space for example - this virtual world really needs decent & user-friendly GI solution without those lightmaps (and it needs to improve some other things too :/ ).

 

Simply matches my thoughts ! So totally agree !

 

+1 for Lex4art's post.
I also fear that the financial return is not as you have planned. If you're looking for further financial source... How about SEClouds? I've seen that you have a wonderful procedural cloud solution for SEUS that looks much better than any other available Sky Asset on the Assetstore. Please bring it over to Unity!

 

Btw, in 2017 there is increase in sales for my 4K materials - finally! (after two years of relatively low sales). Seems that after Adam's demo/Unity 5.5 release there is slowly increasing demand for high quality stuff in assets store, SEGI included I hope ).

 

Single-Pass Stereo Rendering...

 

I came to this thread to see if there was a demo, as we are working with an indoor/outdoor environment that according to the website this plugin can have issues with.

However, our project is also a VR project, so without forward-rendering, we cannot use it (MSAA is a must in our case, as we need super sharp defined geometry).

Our project looks fine with both realtime and baked GI switched off in Unity, but it would have been nice to get some better emissive light support and colored indirect light bounces.

It's sad and surprising to see this project struggling, since it appears to be the top hit in the asset store shader section, and the price is "relatively" high.

 

Interested, any screenshots/demos?

(Concerning SEGI, I also suggest to sell it to Unity. It´s a wonderful piece of software!)

 

Check out SEUS: http://www.minecraftforum.net/forum...80299-sonic-ethers-unbelievable-shaders-v11-0

 

Sorry to come back with a question like that, but is there any news on a particle fix?

Most of the time when we try to test SEGI we do it only in a basic scene, but I don't know any game that wouldn't use particles, and those are still completely broken with SEGI, making it completely unusable for a release so far...

 

There is a fix for that - place particles effects in separate layer & disable this layer in SEGI.

 

Hi SE,
I wanted to ask if you can tell us something about your timeline? Especially GI Baking would be awesome to have, but on your webpages roadmap this task doesn't seem to have gotten any attention, yet.
Please continue your great work.

 

I thought the entire point of this plugin was to not have baking? Otherwise, how can it be "100% dynamic" as the description says?

 

Oh, the obvious use is for mobile - A real-time solution that requires a minimum of setup - if it's then able to bake to lightmap UVs, then it will legitimately blow the Enlighten and Progressive light mappers out of the water in speed and quality. This is desirable for a whole host of reasons - anything that reduces setup, maintenence and bake times increases productivity, and since lighting is one of the most important parts of any game, having SEGI able to bake lightmaps is...incredibly useful and something that I'd be willing to pay 2x the price for.

 

That's basically right for simple scenes, but with very dense, dynamic setups including moving characters and additional image effects it would be great to decide via culling masks what you need to render dynamically and what to bake in order to avoid the jittering and CPU/GPU load in complex scenes.
SEGI just looks way better than what you get from Enlighten.

 

Did you make scenes to compare ? Enlighten baked Vs Segi ?

 

To everybody who wants the good GI Baking - just wait a few months. Unity will include OctaneRender (physically correct render) as the perfect and extremely fast GI Baking solution for free. It will immediately kill any other solution. There is no point to develop any other GI Baking solution..

 

@OnlyVR I never put 2 and 2 together like that. Do you have any sources? That makes too much sense though

 

Just to get the facts right : In partnership with Otoy, whose tools aid the creation and delivery of cutting-edge digital content, Unity announced an upcoming fully-featured integrated version of Unity with Octane Render. Octane Render will complement Unity’s real-time processing by rendering assets offline for beautifull optimized end results in game cutscenes, 360 video, VR, TV, movie, film and much more.

 

But for baking GI: I'm working on a light baking solution that can use SEGI for light calculation. This way one can fallback to precalculated GI that looks identical to SEGI. Apart from that lightmap creation for a whole level should only take around a second with SEGI quality. I've already implemented the lightmap generation based on simple raytracing. It will take a few more months because I'm busy with my main project.

 

I dont want to speculate too wildly about OctaneRender and what it will initially do inside Unity, but I think the best source of info I found so far is this thread which has some rather recent detail from otoy.

https://forum.unity3d.com/threads/additional-otoy-octane-details.463964/

 

Not really, no. Brigade is their own engine, though it sounds like a lot of the speed improvements they made to the pathtracer for Brigade to get it to be real time capable are coming to Octane 4, which sounds like will be coming to Unity. (someday)
https://forum.unity3d.com/threads/additional-otoy-octane-details.463964/#post-3016293

Also to say that "Brigade is designed for realtime GI in games" is simplifying it a bit. Brigade, and by extension Octane 4, are designed for realtime pathtracing, which means real reflections, refractions, caustics, scattering, and perfect shadows (sharp and soft w/ penumbra ...), and yes, "global illumination".

 

OTOY Is Bringing Lightfield Baking And More To Its Unity Integration
https://uploadvr.com/exclusive-otoy-bringing-lightfield-baking-unity-integration/

Brigade. Yes, it is the realtime pathtracing engine for games. But OTOY never claimed it will be integrated in Unity. And it will cost, I guess, around $300-$400. Besides, I don't believe GTI 1080 can handle it, GTI 1180? Maybe. GTI 1280 very likely.
So, today SEGI is the unique solution that provides real realtime GI, it is not perfect, but quite expressive.

P.S. There is another realtime pathtracing engine for Unit available now (free beta) but I am not going to discuss it in SEGI thread.

 

What's the secrecy about? Let us know what asset you're speaking of.

 

as a somewhat recent purchasee of segi, the recent developments seem rather disappointing

 

I presume he's talking about https://rove3d.com/ - no more comments on it, haven't tried it yet myself.

 

Can we stay on-topic? Pathtracing is orders of magnitudes slower than VoxelGI, even if the press text says they're shooting for realtime.
Furthermore, this is a SEGI related thread.

 

Well as that looks just Awesome, i doubt it could serve in real time applications (games), may be in interactive ones. It is a progressive path tracer but you most likely going to wait for a frame to get cleaned up.

The only path tracer that could change things in real time manner is the renderer in Brigade engine from OTOY. They will integrate in Unity the Octane renderer i think, but they are preparing a "Brigade" SDK (API) to be used for implementing realtime GI systems in game engines - this is real time path tracing demo where you can see a clean result at high FPS:

Though the PathTracing is very exciting in general, it is currently too expensive in terms of performance that's why i think Voxel Based solutions like SEGI is probably the one that worth attention yet !

 

Path tracers have some critical list of unsolved problems, like:
- No DXT/BC texture compression (everything is like *.BMP). So, if your game uses 4GB of typical video memory budged you need ~6x more VRAM (around 24GB!) for same scene with path tracing.
- Path tracing drops fps in linear dependency to amount of pixels, e.g. 1280x720 will render with 60fps -> at 2560x1440 it will give 15fps -> at 4K it will be 7.5fps
- Path tracing have serious performance drops rendering trees (tons of alpha-tested polygons).
So, Brigade is on horizon but ... it's there for 5 years at least ). Check raytracey blog...

 

Guys, stay on topic. This is discussion for SEGI - not path tracing techniques.

 

Speaking of SEGI, let's go to @sonicether's place with forks.

And a cake.

 

Sounds very interesting. How do you handle cascading / large scenes?

 

It wouldn't use cascades at all and large levels are no problem. SEGI defines a voxelspace around the camera with the user defined parameters.
The lightmap-baker would then devide the level into these SEGI voxelspaces and iteratively set the position of the SEGI camera accordingly, to get the globillum information needed to bake the lightmaps for each of these voxelspaces.
So i.e. if your level has the size of 100 SEGI voxelspaces it would take 100 repositions of the camera to bake the lightmaps of the level with SEGI quality.
All in all it's not complex to achieve, I just need some free-time after my main project.

 

In general, at least the way I work, if one specific aspect of my project is holding me up because I can't find a solution, I switch and work on other aspects of the project.

Performance shouldn't the end-all, be-all of SEGI, in my opinion. There are other areas that can be worked on, like features and/or usability. For instance, tricks to increase draw distance (which I think is what the cascades have in mind). Improvements aimed at reducing light leaking. Support for point and spotlights. The blue noise is another good one. Think of other ways that the asset can be improved, and let performance be damned (for the time being). No one's going to be looking to drop a beta asset into a production-ready game about to be released,and I think the customers are well aware this is an extremely performance heavy asset and are OK with that.

Keep in mind, that the march of GPU technology never ends. Newer, faster cards are always around the corner. So the performance "problems" may just become a moot point in a year or two because faster cards will handle it as-is no problem.

 

@sonicether This paper might be of use to you on the topic of occlusion. This is for precomputed radiance probes and light field probes (the latter of which isn't as useful right now), but there might be some ideas in there.
http://graphics.cs.williams.edu/papers/LightFieldI3D17/

The video for the GDC talk on this is also up. It's about half way through after the hashed alpha test part (which is also awesome).
http://www.gdcvault.com/play/1024353/

 

I see. And this happens only once when the scene loads I assume.

I'd like to see it in action, and buy it if you release it.

 

So the idea would be to try to get SEGI voxelspaces working like reflection probes, where you can trigger them on awake, and then have them update as needed?

 

The idea is to have traditional lightmaps that work on every device but baked using SEGI lighting instead of Enlighten or the new progressive pathtracer.

With this you can:
1) Enable SEGI if device is supported and powerful enough
2) Fallback to standard baked lightmaps on lower powered devices retaining the same look as in 1). Of course no dynamic GI and no reflections
3) Massivly reduced baking time. (seconds instead of minutes and hours/days)

 

Considering how fast is Octane for example to render a scene, when it will be available in §Unity i am not sure you need a faster lightampper solution.

 

First of all god knows when it will be actually working in Unity and also Enlighten is also an amazing lighting solution. Works great and beautiful in other engines. Just happens to be a piece of crap for a good amount of users in Unity. It is not Enlighten that stinks but its integration with Unity. Octane might be absolutely incredible but what is going to keep it from being half destroyed when integrating with Unity. When it does come to Unity, and highly doubt it will be in a final release in 2017 or maybe even 2018, it might not be the beautiful solution it is as of now. Hopefully it will be amazing but there is no say till it is out and on everyone's desktop.

 

Kind of like how it has gone with SpeedTree, I guess.

 

I don't believe OTOY has any plans on making a lightmapper for Unity useing Octane, and to an extent much of its speed comes from only having to render what's on screen. I think people here have a very skewed understanding of what Octane, Rove, and other pathtracers are for and what "real time" for a pathtracer means. It means if you've got a giant GPU and you stand still for a second you can get something that looks almost as good as something rendered using a high end offline renderer. When the camera is moving you're getting a noisy mess that gives you an idea of what to expect once the camera stops moving. Brigade videos people point to are often running on stuff like dual Nvidia Titans or unreleased prototype raytracing hardware. These aren't really designed with indie games in mind, they're designed for movie pre-vis and architectural rendering where the cost of a few thousand dollars in consumer hardware isn't a huge concern. A high speed action game that can run well and look good on someone's 5 year old laptop is some years off still, unless having a game that looks like mostly static most of the time is the aesthetic you're going for.

Also, even if OTOY made a lightmapper for Unity using Octane 4, I highly doubt it'd be a giant leap faster than the progressive lightmapper Unity has.

SEGI can be slow when the quality is maxed out, but at more reasonable settings can run decently on an average video card. And even then "slow" means 10fps, or 100ms to get to the best quality on a mid range GPU, vs 1000+ms for Octane on a high end GPU.

 

Again off topic but this is what happens naturally in situations like SEGI got into.

Is this what he is talking about - watch at 1:00 m
Plus a path tracer is coming to be used in real time - first for HighEnd GPUs and later thanks to PowerVR (which are developing OpenRL) will come even to mobile devices !

 

Sorry to continue to disrail the thread but I wanted to touch on this.

Enlighten works perfectly fine as long as you only use the part of Enlighten everyone else does, the real time GI part. Battlefield 3 is the first major game to ship using Enlighten's real time GI, and Dice has done talks on how much work they had to do to support it ... as well as rewrite most of it ... to make it viable. The Enlighten we have today in Unity and UE4 (and used in other games) bares little resemblance to what shipped with Battlefield 3 because it was simply too much work to support it from the content side, as well as too expensive to render at the quality they wanted. It took many years and many iterations to get it to where it is today where it mostly "just works".

However I am unaware of any other game that has shipped using Geomeric's Enlighten lightmapper. UE4 uses their own lightmapper they've been working on since Unreal Engine 3 days for example. Early Unity 5 games might have been the first time it's been used in real production! If you want to discuss and complain about their move from Beast to Enlighten, there are several threads on that topic elsewhere, but make note that every game company I know of has moved away from using Beast so one can guess the blame here could be on Autodesk.


Now some people might point out that UE4 supports some features of Enlighten that Unity does not, but I guarantee you some of those features were actually written by Epic themselves and may require engine feature that Unity does not have. Unity has a number of unique features they've gotten into Enlighten as well, but they're less obvious and flashy and more trying to get people who moved from Unity 4 in a better place where as Epic seems more willing to break backwards compatibility or require their users to manually merge features themselves. This has been the case for a long time btw, as a long time Unreal Engine dev you basically had to lock the engine version you were using early in the project and manually merge in the fixes you needed, then either decide to chuck everything and get the latest engine version when you started the next game or try to keep all of your custom changes.

 

You are right, it does sound like they're supporting a light mapper of some kind ... but he makes a mention about it "all being baked" and "the octane renderer handles all of that for you". The translation for that is it being baked into a format that their Octane renderer can use to playback an effectively prerendered scene on top of geometry. He makes no mention of this being something usable by the Unity renderer. I also suspect it only looks totally correct from a basically fixed or very narrow camera position. It's not unusual for a "lightmap" in an offline renderer to store specular highlights and reflections because the camera position is fixed.This is a terminology issue for people hearing words that mean one thing for real time and something very different for offline rendering. For Octane they're probably being a little smarter to let the camera move around more in the scene, but it's not going to be the general case you're thinking of.

I mentioned this already, see that video at around 3 minutes to see what true real time currently looks like, and that's probably being demoed using an Nvidia Titan or two on a fairly small (ie: low resolution) viewport. To be fair it's also probably Octane 3. Brigade and Octane 4 look amazing, but who knows when the PowerVR hardware will materialize, if ever, especially on mobile. With Apple dropping PowerVR in less than 2 years, and Intel killing off Atom there aren't going to be a lot of devices running Wizards (the name of PowerVR's upcoming raytracing capable GPUs), and even if Apple ships with a Wizard in the interim there's no guarantee they'll expose those features. Makes it a hard sell for devs to spend the time to support as you can bet there won't be comparable hardware support in any of the Mali, Adreno, or Tegra parts.