OTOY Forums

yes, thanks lino,

your method works exactly right. i tried all these values but was winging it and could get the results that looked ok. worse, the camera has its own settings too, which makes troubleshooting hard. i would not say its the most intuitive in any case.

but there was also an issue (or my ignorance) of controlling the sun and sky intensity separately. i mentioned in this thread a couple of times.
there are also other questions i have had regarding the "power" values causing completely different results when going back and forth from 0 and 1. i have described them and put up both screenshots as steps and the blender file.
this really looks like a bug and what i was referring to with my "unusable" complain. similar thing happened with a fog box recently and i posted about it with screencaps. (going below a certain density wasn't incremental anymore but the fog would just disappear entirely.)
i wont go into the discussion about the blender plugin. you say its fine, people love it, thats great. octane is gorgeous no doubt about it. but when the parameter values dont produce expected results its impossible the troubleshoot and not usable to me personally.

again a subjective opinion, but the unreal implementation feels far tighter with the host- even with warts and all: native material, texturemap support and all the different lights types(not only area light) enable me to shade and light in the native viewport or go back and forth between UE and octane if needed. cinema4d IIRC also had this ability.

i am not trying to criticize anyone's work. if i understand well each plugin is developed by one person which in some cases mans the forums too. my impression is more resources could go towards those that develop these plugins, thats all.


back to your example: i got the sky looking good but i dont have the direct sunlight and casted shadows as you do. as grimm suggested i can use my exr as a skybox in the daylight system and have sun that way, but i dont understand how you made your setup. you have the same texture env setup as i (attached image) but a different look.


a general question:
i´d prefer to work and render in blender and not mess with exporting alembic and fbx to unreal. i was under the impression that rendering is faster in unreal but you mentioned that each plugin should perform the same.
are there any options or hardcaps setup in unreal out of the box that are optimized in any way? if so, what could i tweak to get close to that performance?

second question, is there any chance that atleast image texture maps of native blender and octane could ever be compatible? the idea being that one could use eevee for viewport and octane for rendering and setup independent shader trees that just share the same image maps.

crackfox wrote:yes, thanks lino,

your method works exactly right. i tried all these values but was winging it and could get the results that looked ok. worse, the camera has its own settings too, which makes troubleshooting hard. i would not say its the most intuitive in any case.

There's a reason why we have Imager and Post Process for Camera as well. If you select Override in the "perspective" versions of the Imager and Post Process, you don't even have to care about it at all.
Most of your confusion comes from Color Space settings. That's how you should always setup your Color Management options when working with Octane in blender:

Expand Color Management and set:
* Display Device: sRGB
* View Transform: RAW
* Look: None
* Exposure: 0.0
* Gamma: 1.0
------------------------------------------------------
2. Go to camera tab in Properties window and enable Octane Camera Imager (Render mode)
------------------------------------------------------
3. Alternatively go to 3d view Properties panel (N key shortcut), locate Octane Camera Imager (preview Mode) and enable Override. This way all cameras will have the setting from this panel.

- And, least but not last, the gamma of your HDRI needs to be set to 1.

but there was also an issue (or my ignorance) of controlling the sun and sky intensity separately. i mentioned in this thread a couple of times.
there are also other questions i have had regarding the "power" values causing completely different results when going back and forth from 0 and 1. i have described them and put up both screenshots as steps and the blender file.
this really looks like a bug and what i was referring to with my "unusable" complain. similar thing happened with a fog box recently and i posted about it with screencaps. (going below a certain density wasn't incremental anymore but the fog would just disappear entirely.)
i wont go into the discussion about the blender plugin. you say its fine, people love it, thats great. octane is gorgeous no doubt about it. but when the parameter values dont produce expected results its impossible the troubleshoot and not usable to me personally.

There's no concept of separated Sky and Sun intensity in an HDRI. When you change the intensity in the Image node or in the Texture Environment node (which are doing the exact same thing), you're changing the whole image intensity:

https://youtu.be/17AWxCMVKTM

If you need to control the Sun in a scene separately, you need to use the Daylight Environment and then connect an HDRI (without sun in it, you need an "overcast" image in this case):

https://youtu.be/6tFwjbSJWIE

I've used your HDRI which is not "overcast", so of course this results in the presence of 2 suns in the scene.

The Environment options in Octane for Blender work exactly as in Standalone or Cinema, there's really no difference.

Please check out this "live performance" in Octane for Blender:

https://youtu.be/_togTU5Iub8?t=6632

again a subjective opinion, but the unreal implementation feels far tighter with the host- even with warts and all: native material, texturemap support and all the different lights types(not only area light) enable me to shade and light in the native viewport or go back and forth between UE and octane if needed. cinema4d IIRC also had this ability.

i am not trying to criticize anyone's work. if i understand well each plugin is developed by one person which in some cases mans the forums too. my impression is more resources could go towards those that develop these plugins, thats all.

Octane for Blender implementation is as tight as it can be.
Octanerender offers 4 light types (Distant/Sun - through the Daylight environment, Area, Spherical and Spectron Spotlight).
All of those are available in Octane for Blender, but the Spotlight.
I know I'm repeating myself here, but the Octane for Blender developer has done an awesome job with the integration so far in terms of features and stability, especially considering Blender Foundation is releasing new versions very quickly.

back to your example: i got the sky looking good but i dont have the direct sunlight and casted shadows as you do. as grimm suggested i can use my exr as a skybox in the daylight system and have sun that way, but i dont understand how you made your setup. you have the same texture env setup as i (attached image) but a different look.

My setup is very similar to the one in your original scene. I just fixed the color space related issues and the HDRI gamma (you can see the options for the environment in the videos I linked).

a general question:
i´d prefer to work and render in blender and not mess with exporting alembic and fbx to unreal. i was under the impression that rendering is faster in unreal but you mentioned that each plugin should perform the same.
are there any options or hardcaps setup in unreal out of the box that are optimized in any way? if so, what could i tweak to get close to that performance?

I never used Octane for Unreal, but render performances are relative to Kernel type and the relative options. Direct Lighting is generally faster than Path Tracing, for example.
Octane for Blender performances are absolutely similar to the ones you get in Standalone.

second question, is there any chance that atleast image texture maps of native blender and octane could ever be compatible? the idea being that one could use eevee for viewport and octane for rendering and setup independent shader trees that just share the same image maps.

That would require time and would be limited to UV textures only, no other projections. I personally like the idea, even if i think Brigade will make Eevee a thing of the past.

thank you for your reply.

i have done an exact same setup as yours with the hdr and have gotten different results, and have provided a screenshot with the relevant values and parameters all visible.
my feeling is something is not right but i am happy to finish this convo and not take any more of your time.

also the whole brigade is confusing to me. earlier in a different thread i was bemoaning the wait for brigade (my "perpetual waiting for godot comment") and the answer was that the tech from brigade has already been implemented and we have seen the benefits of it.
now you say its yet to be implemented and will make eevee obsolete. i dont get it but, again, thanks for your time.