Octane Lightmapping in Unity takes seconds, not hours

I'm concerned about blurry image and noise in the shadow area.

Either way:
When it is going to be available in unity, and under which conditions? Is it a paid asset or ...?

 

Is that set up correctly? Imho the bounced light in the cast shadow falls off too quickly. Iirc light falloff should be inverse to square distance.

 

My test is in the worst possible case. You can use direct lights without any noise and 10X faster bake time

I read about octane that will be free for unity users. Also you can use cloud service subscription
PLM :

 

Used default settings (in path tracer) with maximum samples and quality (44.000 samples done in this image)

 

Is your project set to use linear or gamma colorspace? To me both still look wrong, but in the same way. So I'd search the error outside of light baking. HDR, linear colorspace, post stack with filmic tonemapping - that's what I would try.

Thanks for working on these comparisons. Do you have a guesstimate by what factor octane is faster than the progressive mapper?

 

Still not happy with the second result. Looks like a path tracer renderer that has number of bounces set to too low. (Although the first one, to be honest, reminds me of Quake 3 era 16 bit images)

Would be nice to have a test scene uploaded. Or something.

 

Actually in this test light settings was not based on real world and was hacked to see maximum possible Indirect Light/Shadow distance in both renderers (As you can see Beast couldn't reach to this distance of the falloff)

Linear color space
Post Processing stack (color grading ACES)

All path tracer renderers used same mathematic algorithms and the fight is on RenderSpeed and Noise amount side:

Why Octane should be better ?
1. GPU baking. Now we can use multiple GPUs easily. But using multiple CPUs is not possible in unity
2. When you are using GPU, your cpu usage is free and you can work on your desktop without performance issue. But when you are rendering using PLM, you must leave your pc until end of the bake
3. GPU baking has a lot faster preview feedback after starting the render. But needs much time to reach to a noise free look
4. RAM usage is low in octane (maybe). SO you can bake too many tree models without problem. It's not possible in PLM
5. Support for NormalMap baking or other elements (AO,Specular ...) - Maybe

PLM benefits :
1. Fully compatible with Light probes, mixed mode and light settings
2. Maximum quality in indirect light and shadows (it's not possible in low amount of the RAM)
3. Integrated into the unity light mapping work flow

 

You must wait a few hours to get a clean render
Or use filters (A-Torus ..) to get smoother lighting result in a short time (second image used in PLM)

 

That one I don't understand.

If octane is anything like blender cycles (which I assume it is) then RAM usage is low by design because the whole scene at once needs to fit into VRAM on the GPU. Trees are a typical example where with instancing you would be able to relatively easily have millions of the same object, but without instancing you'd very soon hit a brickwall where you just can't bake because the scene doesn't fit into VRAM anymore. In Multi-GPU setups in blender I think the limit is that your complete scene must fit into the VRAM of your smallest GPU for all GPUs to be used. The upside is that you can freely combine different GPUs in non-SLI setups. E.g. I'm using a gtx 1060 and a gtx 660 in tandem for rendering in Blender.
I'm not sure how Octane handles or plans to handle the whole-scene-in-VRAM limitation. Blender has something for that either on the roadmap or recently implemented. I'm not sure because I almost never hit that limit in my work. I would consider though, that swapping between RAM and VRAM could introduce huge slowdowns compared to a scene that can just stay in VRAM during the whole baking process. It remains to be seen if they will come up with sensible spacial partitioning structures that would be able to bake a level in "chunks" of geometry that are chosen in a way that data that has no actual influence on the currently baked chunk does not need to be transferred into VRAM.
I'm having high hopes for this kind of GPU baking, even though I'm still likely to avoid everything that requires any kind of editor-time baking, because I find runtime procedural generation just fits a whole lot better to what I like to work on.

 

I believe it might be a good idea to distinguish between Enlighten and Progressive Lightmapper, which are not the same thing.

Either way, I threw a scene together. Feel free to wreck it.

Blender render:

Unity render:

 

Unity 2017.1.0f3 + Octane 3.07

1920x1080, render time: 2m 6s, Kernel Max. samples: 1000


1920x1080, render time: 10m 3s., Kernel Max. samples: 5000

 

some 4k fast renders in Unity with Octane from free sketchup models

 

You need to kill skybox reflections on lighting tab. It tints everything blue. Blender scene was rendered with 0x404040 color ambient.

 

That's better, although the Octane renderer still feels a bit fuzzier somehow.

What were the settings? My computer was chewing the scene for quite some time, so I only tried that relatively quick enlighten render. Which was blurry.

 

ok.
1920x1080, render time: 1m 59s, Kernel Max. samples: 1000


the white stars are from point lights - when disabled - gone - sphere is emmisive octane material

 

Takes about 200 seconds to bake to 5000 samples on this laptop at 8k x 4K.

 

Man, is this a tease? lol
link to download?
link to tutorial?

 

I expect stuff like this will come in time anyway, but it'd be great to see results on a real-world game scene, like something from Adam* maybe?

* Yes, I know that's technically not a game.

 

Viking village is available on asset store. And so is blacksmith.

 

this is not fair - for standard users there's no octane version working with 2017.1.1

 

I think Octane Lightmap baker is just an tool like texture baking and it's not a automatic light mapping workflow

 

https://docs.otoy.com/UnityH/UnityManual.htm#Unity/LightingAndTextureBaking.htm
https://docs.otoy.com/UnityH/UnityManual.htm#Unity/Lightmapping.htm

 

^Yeah, exactly. I should've posted about this earlier, but when I went into the Otoy manual and it showed and empty section for lightmapping, I just assumed the feature was still under development.

Seeing the .gifs from the CEO's Twitter - and the post above - is really encouraging, however, I'm already excited. I need concrete details at this point, not more hype.

 

We are still working on the automation of the UV regions across multiple objects unwrapped by Unity - in all the video demos, this full scene baking system was set up by hand (i.e. using sub-UV regions in the baking render to texture) . There will basically be a mode like this during authoring will bake the entire scene at once in real time (including any light probes) in whatever buffer size you can support in a single render texture (as in the videos), the other will generate even higher quality offline baked versions (including on the cloud), that can be at gigatexel resolutions . Note we only have AO and shadow and raw lighting AOVs in Octane (and 9 order SH is trivial to generate), we are working on directional light mapping AOVs that support traditional Unity lightmapping system: https://twitter.com/icelaglace/status/920845476680699904

 

So we will not have seamless lightimapping workflow like unity PLM or Enlighten ?

 

Really appreciate you stopping by to drop some more details, thank you!

 

Yes. it might take a few releases from here to get this polished and cover all you would need to replace these, but that is absolutely the idea. With Octane 3.08 (in testing now and will be pushed to Unity soon), you have both an OSL camera and OSL texture system, which can be used to generate all sorts of pre-computed maps and projections beyond what is currently possible in this build.

 

Anytime! This kind of user feedback is great!

 

Will directional lightmaps be supported?

 

I've been in my trench in 4.7.2 due to lack of proper lightmaping in 5.x. I was using a Beast + an extensión that unleased all the power of it. I latelly wanted to upgrade due to singlepass, gpu instancing etc but this feature definitelly forces me to move! (well, after testing to work with mid-big sized urban scenes )

 

Would this work in run-time builds? Would be really useful for procedural stuff or real-time/dynamic setups. For now most of us are using SEGI.

 

Not in the first drop, but it is being worked on:
https://twitter.com/icelaglace/status/920845476680699904

 

SEGI is beautiful. We are testing a feature in 3.08 (next Octane version, first drop this week) that exposes OSL to drive the camera rays. This means you can render into volumes, voxels, anything you can think of really. I think it might be a starting point for VXGI type approaches. In Octane 4, we hope to have real time path tracing working in runtime playback, not just Editor/Game mode, but in deployed games and apps (exact mechanism TBD).

 

Hi,
I found way to make fun with bake lightmap in scene view with Octane:



I use for that script SetLightmapsManually.cs from this tread https://forum.unity.com/threads/lightmap-index.307555/
Steps to do that:
1. Create PBR Render target component for each mesh and set Camera =>Render target and choose Baking camera
Set unique Baking group ID for each mesh - exactly the same that is set in mesh in PBR script
2. Render, and create new render texture and name it like mesh
3. Add script SetLightmapsManually.cs to each mesh, and set Ligtmap Array to number of baking meshes - in these example I set to 2.
4. Add created lightmass textures to Lightmap array to element 0 and 1 - in these example I add cover map to 0 and floor to 1
5. Start bake lighting in Lighting tab with progressive lightmapper (I don't know why - but without these this not working) - and stop and uncheck "Auto Generate"
6. In each mesh clik in SetLightmapsManually script - first Set Lightmap Array checkbox, then Set Lightmap Value.

In these example Floor parameters are: Ligtmap Index: 1, Cover: Ligtmap index 0

But these nice lightmaps from Octane dissapear when press play - don't know why - mayby someone can figure out why and can fix that ?

I know, that it's for fun only - but if we don't have a ready baking solution from Otoy - why not to make some fun ?

 

Cool!

 

I'm guessing, but it's because since the atlas settings are not saved on the mesh renderer any more, at runtime it loads them from the Lighting Data asset (so it overrides whatever you used to bake the lightmaps in Octane).

You either need to figure out how to make the atlas settings write to lighting data (which I'm not sure if it's doable, never looked into it), or you need to reset the atlas settings once per mesh renderer at runtime, which is definitely doable.

 

It's simple to create an editor window to do these steps aromatically
I will check it in action soon

 

@OTOY what is pricing?

 

This appears to be a workaround though - which is great! - but, presumably, @OTOY will be implementing an official solution for lightmapping in Unity scenes(?)

 

Pricing is on their roadmap about halfway down.

https://unity.otoy.com/roadmap/

 

My mistake - Octane working even in Unity 2017.3 beta

 

What I expect from Otoy's Unity plugin.

-Offline quality path traced light backed into lightmaps
-Super fast light preview, ( with clip región for big scenes to compute only selected área, clip región could simply view the in viewport rendered area )
-Reasonable speeds for production (from some minutes to overnight render if scene like 5km x 5km ). Please it be progressive.
-Dual lightmaps so I can lit player vehicles and characters with RT shadows.
-"Unlimited" lightmap size due to use of megatextures
-Option to bake more than one lighting setup for a single scene, like daylight/overcast/nightime

If that happens then will be what Unity should have brought us after removing Beast, instead the forever precomputing solution.

 

Pricing is more than reasonable, however it remains to be seen what GPUs are supported.

 

I don't think there is any mystery about that - I know they talk of increasing compatibility one day, but so far this stuff is CUDA-based so Nvidia only.

 

Yeah so, it's not the holy grail people are thinking it is yet

 

To me this is perfectly ok. Having Nvidia hardware is not such a big deal, you can get some decently cuda core feeded card at absolutelly affordable range.

To me the holly grail ppl is asking in many places in the forum is realtime GI with Path Tracing quality, and running in my laptop at single pass VR...

The overall expectations on GI performance from devs seem to be quite above reality. Atm, the truth is that Unity can´t even deliver properly baked lighting when you get just a bit complex in your scene. (I recon have not tested progressive lightmapper but ppls testings leave it quite below expectations and former performance of Beast). So I would first whant to see the photoreal lightmaping thing nailed and move afterwards into something more dynamic, that may or may not take advantage of existing lightmaps or precomputed data etc. IMO in 5.x, in regards to lighting ,tried to bite more tan they could chew and the outcome was a non production ready lighting solution for any mid and up sized Project.

 

Thank you for your infos
It's so easy to use unity lightmapping shader (or custom shader with lightmap texture support) and assign it using script
My simple test :

 

I know that you can make it.
Can you show your PBR object settings ?