OctaneRender™ Standalone 3.04

[doca]

One more thing, there is often negative pixel value, and mostly in the blue channel. It can be solved with clamp or grade node in Nuke, but does it have influences in calculations how image is rendered? Is it correct render? Are the reflections/refractions/sss... corect?

[gah5118]

in my case, I do render everything to the same folder. After render, I have a batch process that I run in photoshop that looks at the same folder. I'm sure some others may work similarly, however, in other cases, per project basis, if the file path were saved in the renderjob node, then you only do it once for that project... not everytime.. in my case, i do it once then i'm done. after photoshop runs the batch process over all the renders, i move them to their project folder. this is why in my case, which isn't really relevant to some, I would save it and throw it in my localdb to drag into to my setups. It will none the less add versatility.

to throw out there again and if i'm not explaining this well, let me know and i'll try again: a master render node where all other render nodes connect to. This way you select the master and it processes the connected nodes. In my case as an example, I have an alembic node which contains all of my main "plates" (I use animation not as animation but as individual images). I also have render targets that have separate orthographic views. At the moment I have to set up multiple render batch jobs for each render target which means having to execute each node by hand. if there were a "master render" node that all of the render job nodes can hook up to, then one execution would be necessary.

love the batch render node. One improvement that would be great; add the file path selection to the main node rather than asking when running the render. This way, the node can be saved to your localdb and reused with the same settings every time.

I don't fully understand. Why would you always want to render into the same directory? Or do you mean something else?

Gah's argument about saving batch render job to localdb is confusing and has nothing to do with the Output Folder problem.

The point is : why would you want to have to set the Output Folder everytime you run the batch render job ?
Output Folder shouldn't be an interactive step, but should be one of the the imput of the batch render job.



Also considere to change the default filename template from %n_%f_%p.%e to %n_%p_%f.%e,
because most of the applications need frame number to be at the end of the filename to recognize an image sequence.

[TRRazor]

Bump and normal maps can now be rendered together

It sure was about time...
Something so fundamental - I'm surprised it took so long for this to be implemented in the first place.

Thanks for this

[Jolbertoquini]

Thanks Guys,
I have a quick question for the new falloff modes Could we have based on luminance??

Hi Guys,

Could you me a answer please about that if is possible.

Best,
JO

[abstrax]

Thanks Guys,
I have a quick question for the new falloff modes Could we have based on luminance??

Hi Guys,

Could you me a answer please about that if is possible.

Best,
JO

What exactly is it supposed to do? Could you give me an example? Thanks.

[calus]

As normal map has been revisited in 3.0.4 to work with bump map,
I was expecting the other normal map limitations to be removed.

But the material normal map pin still only support imagetexture as input,
and the power pin of imagetexture node still doesn't work for normal map (input is converted to grayscale).

So it's still not possible to mix normal maps together in 3.0.4,
this is a major issue as we can't support UDIM for normal map in DCC plugins because of that.

[gah5118]

another feature for the render job node: resolution override.

When setting up the scene I usually work in 640x480 and when running the job, its always a fun time when you realize you forgot to set your desired resolution. Being able to override this would solve this issue.

[BorisGoreta]

Would be great if we could get the total number of emissive polygons in the scene together with other statistics. It would be useful for scene optimization since emissive polygons are slowing the render down and introducing noise. So some little polygon which is a part of some model could be easily forgotten. It could stay on even if it is not visible in the scene and thus not needed at all.

[abstrax]

As normal map has been revisited in 3.0.4 to work with bump map,
I was expecting the other normal map limitations to be removed.

But the material normal map pin still only support imagetexture as input,
and the power pin of imagetexture node still doesn't work for normal map (input is converted to grayscale).

So it's still not possible to mix normal maps together in 3.0.4,
this is a major issue as we can't support UDIM for normal map in DCC plugins because of that.

The reason for that is that we currently have two ways to evaluate shader trees: Either as float (greyscale) value or as spectrum. The normal map would need to have the texture to be evaluated as RGB triplet instead. So duplicating and converting the spectrum texture evaluation to RGB triplets is quite a massive change which we don't want to do now. When we've got OSL running we will look into this again.

[abstrax]

another feature for the render job node: resolution override.

When setting up the scene I usually work in 640x480 and when running the job, its always a fun time when you realize you forgot to set your desired resolution. Being able to override this would solve this issue.

Ok, will put it on the to-do list.