OctaneRender™ 2020.1 RC2 [superseded by 2020.1 RC3]

Forums: OctaneRender™ 2020.1 RC2 [superseded by 2020.1 RC3]
A forum where development builds are posted for testing by the community.
Forum rules
NOTE: The software in this forum is not %100 reliable, they are development builds and are meant for testing by experienced octane users. If you are a new octane user, we recommend to use the current stable release from the 'Commercial Product News & Releases' forum.

Re: OctaneRender™ 2020.1 RC2 [latest 2020.1.x]

Postby linograndiotoy » Sun Mar 15, 2020 10:18 am

linograndiotoy Sun Mar 15, 2020 10:18 am
Kanne wrote:I have an issue with faceting, i'am not sure since which release it occures. I opned a thread in the daz3d plugin section where i thoughed it would inheriate from the sss channel but it seams to be a general issue. (viewtopic.php?f=44&t=73989)

I created a simple scene with a spehere with a simple glossy material (Smooth is enabled) and a plane to light it. Even there the faceting is visible. i know i can reduce the effect by increasing the subdevision but there are cases where i dont want to.
The attachment Faceting.png is no longer available


Is this an issue, is this a problem of settings?

I attached the simple scene.


You should increase the number of subdivisions in the primitive.

facet.PNG


Changing the value of Ray Epsilon can also help:

facet_02.PNG
linograndiotoy
OctaneRender Team
OctaneRender Team
 
Posts: 1148
Joined: Thu Feb 01, 2018 7:10 pm

Re: OctaneRender™ 2020.1 RC2 [latest 2020.1.x]

Postby Kanne » Sun Mar 15, 2020 3:32 pm

Kanne Sun Mar 15, 2020 3:32 pm
linograndiotoy wrote:
Kanne wrote:I have an issue with faceting, i'am not sure since which release it occures. I opned a thread in the daz3d plugin section where i thoughed it would inheriate from the sss channel but it seams to be a general issue. (viewtopic.php?f=44&t=73989)

I created a simple scene with a spehere with a simple glossy material (Smooth is enabled) and a plane to light it. Even there the faceting is visible. i know i can reduce the effect by increasing the subdevision but there are cases where i dont want to.
Faceting.png


Is this an issue, is this a problem of settings?

I attached the simple scene.


You should increase the number of subdivisions in the primitive.

facet.PNG


Changing the value of Ray Epsilon can also help:

facet_02.PNG


Like i said, i dont always want to increase subdivision because of performance reasons. Increasing Ray epsilon helps, but on characters with geo shells or other very close surfaces you will get artifacts.
Both ideas help in certain scenarios but arn't final solutions, atleast in my opinion. To me this appears to be a bug, dose it?
Kanne
Licensed Customer
Licensed Customer
 
Posts: 78
Joined: Wed Mar 06, 2019 5:51 pm

Re: OctaneRender™ 2020.1 RC2 [latest 2020.1.x]

Postby linograndiotoy » Sun Mar 15, 2020 3:59 pm

linograndiotoy Sun Mar 15, 2020 3:59 pm
Kanne wrote:Like i said, i dont always want to increase subdivision because of performance reasons. Increasing Ray epsilon helps, but on characters with geo shells or other very close surfaces you will get artifacts.
Both ideas help in certain scenarios but arn't final solutions, atleast in my opinion. To me this appears to be a bug, dose it?


Well, no, not a bug. That's the way most renders work. OpenGL works differently. Adding subdivisions is important to get rid of artifacts when using a path tracer.
Ray Epsilon works quite fine, even when you're dealing with close geo.

RayEps_03.PNG


That's the same scene with the default Ray Epsilon value:

RayEps_04.PNG
linograndiotoy
OctaneRender Team
OctaneRender Team
 
Posts: 1148
Joined: Thu Feb 01, 2018 7:10 pm

Re: OctaneRender™ 2020.1 RC2 [latest 2020.1.x]

Postby mojave » Sun Mar 15, 2020 6:53 pm

mojave Sun Mar 15, 2020 6:53 pm
galleon27 wrote:I have an issue with the way Surface brightness in Lighting works (Blackbody/Texture).
When it is ticked off, the light should be the same intensity no matter the size of the object. That works fine with size, but not with scale. If you scale the object, the intensity changes and that really shouldn't happen.
That is an issue cause in Houdini plugin, the Octane light object is a plane with a Blackbody texture and the only way to determine its size is by scale, not size. It can be fixed on the plugin side by letting me set the size of the plane but i think its wrong the way it works now. Scale and size should be the same thing as far and surface brightness is concerned.


Thank you for your report, we will look into this.
User avatar
mojave
OctaneRender Team
OctaneRender Team
 
Posts: 1259
Joined: Sun Feb 08, 2015 10:35 pm

Re: OctaneRender™ 2020.1 RC2 [latest 2020.1.x]

Postby mojave » Sun Mar 15, 2020 6:55 pm

mojave Sun Mar 15, 2020 6:55 pm
jimho wrote:
jimho wrote:network rendering still fails which will kill the master session, same situation as in 2020.1.RC1,
viewtopic.php?f=33&t=73978&start=40


Found a temporary solution,
the problem comes from the conflict between RTX and ooc, I was used to turned on the OOC on the slave side, not noticing the RTX is on by default, that is the reason the slave will kill the master.

When I turned OOC off (which is actually the deault value) at the slave side, the network rendering works again.


This must be the same issue I mentioned before we are aware of, thank you for confirming that.
User avatar
mojave
OctaneRender Team
OctaneRender Team
 
Posts: 1259
Joined: Sun Feb 08, 2015 10:35 pm

Re: OctaneRender™ 2020.1 RC2 [latest 2020.1.x]

Postby mojave » Sun Mar 15, 2020 7:02 pm

mojave Sun Mar 15, 2020 7:02 pm
Kanne wrote:I have an issue with faceting, i'am not sure since which release it occures. I opned a thread in the daz3d plugin section where i thoughed it would inheriate from the sss channel but it seams to be a general issue. (viewtopic.php?f=44&t=73989)

I created a simple scene with a spehere with a simple glossy material (Smooth is enabled) and a plane to light it. Even there the faceting is visible. i know i can reduce the effect by increasing the subdevision but there are cases where i dont want to.

Is this an issue, is this a problem of settings?

I attached the simple scene.


When you use a triangle mesh this is just an approximation/discretization of some shape, in the case of spheres Octane supports this in all plugins via NT_GEO_MESH using the A_SPHERE* attributes. This is usually used in particle simulations but you may create this type of geometry using a Lua script (please refer to the documentation for more details). Furthermore Octane exposes NT_GEO_OSL which allows creating your own geometric primitives via OSL (AKA vectron). None of these geometry types have the limitiations you see with a mesh so you may want to give that a try if you need a completely smooth sphere without creating any extra geometry.
User avatar
mojave
OctaneRender Team
OctaneRender Team
 
Posts: 1259
Joined: Sun Feb 08, 2015 10:35 pm

Re: OctaneRender™ 2020.1 RC2 [latest 2020.1.x]

Postby karl » Sun Mar 15, 2020 8:53 pm

karl Sun Mar 15, 2020 8:53 pm
rajib wrote:H Parade / Mojave,

I have sent a link to a scene file (via PM to Paride) that will give the OOC error that I have been reporting in Daz plugin and now will crash 2020.1.RC2 standalone too as soon as it starts to render.

I have also noticed something. The Daz plugin problem starts to occur once OOC Memory usage hits around 8GB+. I tested this theory with a fresh new scene file in Daz and I kept adding copies of a multi High-Res models until it started to give me errors that I have been mentioning. I noticed below 8GB it still was able to render in the Octane Viewport without errors but once I crossed that, I started to get Cuda error 2, "Failed to allocate page locked memory. Error 2", "No device pointer for out-of-core memory", "Render engine failure" and even crashes.

I fell there is some difference in the plugin OOC handing code vs the standalone OOC handling code...

Regards,
Rajib


Hi Rajib,

I suspect the difference is that Daz Studio is using more VRAM and/or more system RAM than standalone. There is no different code to handle OOC between the two; the only difference would be the environment in which the code is running.

(I thought I posted this on the RC1 thread but looks like it was somewhere else so the following is largely a copy-paste.)

The maximum amount of out-of-core memory mappable by applications is controlled by the driver and the GPU. Unfortunately we have no way to know ahead of time what that maximum amount is, and it may depend on runtime factors such as what other applications are doing. Generally it's approximately proportional to the amount of VRAM you have, which is why (for example) going from 64 GB to 128 GB system RAM or increasing Octane's out-of-core limit setting past a certain point is unlikely to improve anything. The setting in Octane controls the limit that Octane itself imposes on OOC memory, but there's no guarantee the driver will let you reach that limit.

Since this is out of Octane's control, the best we can do is improve the UI for the relevant settings/warnings/errors, to make it clear what each actually means, to give the user the best chance to have a working setup, and if all else fails to make it clear where the problem lies. I will try to think of some ways we could improve the user experience.
karl
OctaneRender Team
OctaneRender Team
 
Posts: 363
Joined: Sun Oct 13, 2019 11:26 pm

Re: OctaneRender™ 2020.1 RC2 [latest 2020.1.x]

Postby karl » Sun Mar 15, 2020 9:44 pm

karl Sun Mar 15, 2020 9:44 pm
jimho wrote:regard to the nvlink,
it shows much more solid than last version, I think it is a big progress, very happy to see and thanks Otoy,

there are 4 RTX2080ti in my work station, though both are physically linked by bridges, there are only one pair are recognized and configured as sli, since there is limitation from Nvidia's driver,
I tried quite a few times with a big scene, each time the linked pair works,
though the other two normal GPU fails (which are not shown as linked) , only when I uncheck them from the "use priority" box, I got this:
NVlink_test3.jpg

RTX Pool.JPG

means the stability for the combination of linked and unlinked GPU is still vulnerable
hope the nvlinked pair could work togethet with other GPUs soon.

Jim


Hi Jim,

When rendering with multiple GPUs, the entire scene data needs to be able to fit on each GPU (or pair of GPUs, if you're using NVLink). So even though you're using NVLink with two of your GPUs, the other two GPUs each still need to hold all the scene data in order to render. (This excludes any data that goes to out-of-core memory, which can be accessed by all GPUs.)

Since GeForce cards no longer support multiple NVLink pairs, this means you will only see a benefit (in terms of preventing render failures) from NVLink if the number of 2080 Tis you're using for rendering is exactly two (because the point at which we start using memory pooling is exactly the point where the non-pooling cards will run out of VRAM and fail). For scenes where you can successfully render without NVLink but using out-of-core memory, you may see a speed benefit by enabling NVLink because those GPUs will be able to use peer memory to replace some of the slower out-of-core access that the other GPUs will have to do.

Unfortunately I don't think there's anything we can do to address the failures, but I hope this explains what you're seeing.
karl
OctaneRender Team
OctaneRender Team
 
Posts: 363
Joined: Sun Oct 13, 2019 11:26 pm

Re: OctaneRender™ 2020.1 RC2 [latest 2020.1.x]

Postby Kanne » Mon Mar 16, 2020 12:01 pm

Kanne Mon Mar 16, 2020 12:01 pm
mojave wrote:
Kanne wrote:I have an issue with faceting, i'am not sure since which release it occures. I opned a thread in the daz3d plugin section where i thoughed it would inheriate from the sss channel but it seams to be a general issue. (viewtopic.php?f=44&t=73989)

I created a simple scene with a spehere with a simple glossy material (Smooth is enabled) and a plane to light it. Even there the faceting is visible. i know i can reduce the effect by increasing the subdevision but there are cases where i dont want to.

Is this an issue, is this a problem of settings?

I attached the simple scene.


When you use a triangle mesh this is just an approximation/discretization of some shape, in the case of spheres Octane supports this in all plugins via NT_GEO_MESH using the A_SPHERE* attributes. This is usually used in particle simulations but you may create this type of geometry using a Lua script (please refer to the documentation for more details). Furthermore Octane exposes NT_GEO_OSL which allows creating your own geometric primitives via OSL (AKA vectron). None of these geometry types have the limitiations you see with a mesh so you may want to give that a try if you need a completely smooth sphere without creating any extra geometry.


The problem is not the sphere itself, i just used it as an example for a small orbx filesize.
My main issue is a character i try to create a shader for (download/file.php?id=78427&mode=view) From my expectations i thoughed the mesh would be high-res enough. But with high density scattering nodes it seems to become even more visible, like i described in viewtopic.php?f=44&t=73989.
Kanne
Licensed Customer
Licensed Customer
 
Posts: 78
Joined: Wed Mar 06, 2019 5:51 pm

Re: OctaneRender™ 2020.1 RC2 [latest 2020.1.x]

Postby jimho » Mon Mar 16, 2020 2:31 pm

jimho Mon Mar 16, 2020 2:31 pm
karu wrote:
jimho wrote:regard to the nvlink,
it shows much more solid than last version, I think it is a big progress, very happy to see and thanks Otoy,

there are 4 RTX2080ti in my work station, though both are physically linked by bridges, there are only one pair are recognized and configured as sli, since there is limitation from Nvidia's driver,
I tried quite a few times with a big scene, each time the linked pair works,
though the other two normal GPU fails (which are not shown as linked) , only when I uncheck them from the "use priority" box, I got this:
NVlink_test3.jpg

RTX Pool.JPG

means the stability for the combination of linked and unlinked GPU is still vulnerable
hope the nvlinked pair could work togethet with other GPUs soon.

Jim


Hi Jim,

When rendering with multiple GPUs, the entire scene data needs to be able to fit on each GPU (or pair of GPUs, if you're using NVLink). So even though you're using NVLink with two of your GPUs, the other two GPUs each still need to hold all the scene data in order to render. (This excludes any data that goes to out-of-core memory, which can be accessed by all GPUs.)

Since GeForce cards no longer support multiple NVLink pairs, this means you will only see a benefit (in terms of preventing render failures) from NVLink if the number of 2080 Tis you're using for rendering is exactly two (because the point at which we start using memory pooling is exactly the point where the non-pooling cards will run out of VRAM and fail). For scenes where you can successfully render without NVLink but using out-of-core memory, you may see a speed benefit by enabling NVLink because those GPUs will be able to use peer memory to replace some of the slower out-of-core access that the other GPUs will have to do.

Unfortunately I don't think there's anything we can do to address the failures, but I hope this explains what you're seeing.


Hi Karu,
Thanks for your respond and the explanation, Generally it make sense to me, only a small question,
According to your articulation how the multiple GPUs are working, when OOC is on they should be working though slow but not failure, this is my understanding.
though the current situation is:
Even when OOC is on, not every time the non-nvlinked GPU will work, as mentioned: only when I check off the "use priority" box for them, they may work, yet still seems not so stable.

my question is: can ooc and nvlink work together stablely,

in theory the nvlinked pair is just like a big GPU (with more memory), the situation might be similar with mixing different sized GPUs
Consider when we mix different Vram sized GPUs, the situation may be as below:
1) before ooc, when the scene is exceeded the smaller GPU's Vram they will fail (Obviously, that is why we need OOC)
2)with ooc,
2.1) should the small GPU still fail meanwhile the big one keep running (just like before), OOC will start working when the big GPU exeed its VRAM
2.2) the small one could start using ooc, the big one keep running with its internal Vram,
2.2.1) further to the 2.2, when the big one is also running out of Vram a second mark point can be made, to let the big GPU know it's OOC starts here, only after this point the big GPU will go OOC,
Means different mark point made for different sized GPU to make them all utilize the system memory, they can share the data but will not conflict to each other.

Currently what we see is probably the case 1 and 2.1,
Ideally is it possible that we go the 2.2 scenario, if this 2.2 senario could work for mixed size GPUs the nvlink pair could act just like the big gpu, then ooc and nvlink could both work...

or is there a better possibilty that just let the GPUs not fail...

I am not a programmer, above thoughts just for your reference
Many thanks,
Jim

Supermicro 4028GR TR2|Intel xeon E5 2697 V3| windows 10| revit 2019 |Titan V+ Quadro GV100+RTX 2080 Ti
jimho
Licensed Customer
Licensed Customer
 
Posts: 262
Joined: Tue Aug 21, 2018 10:58 am
PreviousNext

Return to Development Build Releases


Who is online

Users browsing this forum: No registered users and 3 guests

Fri Mar 29, 2024 1:58 am [ UTC ]