For each DAZ surface in Surfaces create accumulator buckets for...

nonesuch00

For each DAZ surface in Surfaces create accumulator buckets for...things such as 

memory used per surface

time spent computing the surface (if possible also broke down by light calculation type)

ram used for each surface

and other resources but may be other resource types besides surfaces, eg HDRI dome calculations and so on...

And a dockable resource usage accumulator pane

That's all.

 

wolf359

Hi may I assume that one would want this information for better user controlled scene optimization??.

To identify the resource "hogs"??

This being the case one would need a high degree user level controls over what aspect of your scene or render settings could  be dialed back based on this efficiency reports  correct?.

nonesuch00

wolf359 said:

Hi may I assume that one would want this information for better user controlled scene optimization??.

To identify the resource "hogs"??

This being the case one would need a high degree user level controls over what aspect of your scene or render settings could  be dialed back based on this efficiency reports  correct?.

Well yes, but realizing one would be sacrificing some of the calculated realism in doing such throttling adjustments or you could choose another surface material that would eliminate or reduce the problem if the currently used resource intensive surface material wasn't crucial to your scene.

Also, it would help alorithm designers of future iterations optimize their code or test out completely new algorithms that are faster and easily be able to measure the effect although I'm not sure how you'd compare two images that should technically be the same despite using two different algorthms to compute those images. The experts on the physics of light would have to determine if the differences between the images where still both acceptable representations of the light. Sort of like those two light and color profiles they added to the DAZ Studio 4.9.3.166 version of the iRay Renderer  are deemed acceptable representation despite calculating somewhat different images.

wolf359

Hi many "professional" rendering engines  do offer very specific levels of control even on a per material basis.
For example We have modo and we can direct it to use monte carlo
 but only on a fur material as opposed to radiance cacheing every where else, which has less noise  but the noisier monte carlo can still look decent on a noisy material like fur.

Of course the ability to set the number of bounces for reflective/refractive materials is in Modo as well as blender in Branched path tracing mode.
I dont see how a console panel displaying these parameters would be helpful as most engines have the scene loaded into memory and wont allow you to make such changes during the render other than lighting intentsity/color as we can now with Maxwell or LUX.
These are all features of the render engine itself not the application to which they are ported. 

Of course once you start tinkering with these parameters you technicly move out of the realm of 
"unbiased" or even PBR rendering as you are imposing your own "biases" on how the lighting is interpreted.

I personally consider these Good options but 
PBR purists my  Disagree.

 DAZ Studio IRay's Dumb Brute force approach  appears to be acceptable to most users who have the required NVDIA hardware.
so I doubt DAZ would or even could implement such extended controls 
with daz studio accept as a third party addon to do the monitoring.  

Serene Night

I could really use this. I'm running into long render times for certain scenes and content and knowing what is hogging my computers resources would be useful

nonesuch00

wolf359 said:

Hi many "professional" rendering engines  do offer very specific levels of control even on a per material basis.
For example We have modo and we can direct it to use monte carlo
 but only on a fur material as opposed to radiance cacheing every where else, which has less noise  but the noisier monte carlo can still look decent on a noisy material like fur.

Of course the ability to set the number of bounces for reflective/refractive materials is in Modo as well as blender in Branched path tracing mode.
I dont see how a console panel displaying these parameters would be helpful as most engines have the scene loaded into memory and wont allow you to make such changes during the render other than lighting intentsity/color as we can now with Maxwell or LUX.
These are all features of the render engine itself not the application to which they are ported. 

Of course once you start tinkering with these parameters you technicly move out of the realm of 
"unbiased" or even PBR rendering as you are imposing your own "biases" on how the lighting is interpreted.

I personally consider these Good options but 
PBR purists my  Disagree.

 DAZ Studio IRay's Dumb Brute force approach  appears to be acceptable to most users who have the required NVDIA hardware.
so I doubt DAZ would or even could implement such extended controls 
with daz studio accept as a third party addon to do the monitoring.  

Well I can't afford Modo, but even if DAZ Studio didn't allow alterations of these accumulator buckets to keep the 'PBR' render 'pure' those bit buckets are still very valuable to developers - if they've created good code they can easily change the algorithm in an attempt to improve it and develop measure the effects accumaltively and directly in the accumulator buckets. nVidia would be wish to use DAZ Studio as one of it's suite of programs for testing and improving their iRay renderer. It is free and used extensively.

And not allowing the alterations of a strict PBR interpretation by the end users doesn't eliminate the value of a artist having the accumulated information of the rendering surface buckets either as they often have to compromise between productively or realism. You see their compromises all the time as ad copy in the DAZ Store. They could improve their renders and make better more realistic rendering compromises given the correct information. The buckets would directly show them resource intensive surfaces and they could develop and adapt their scenes to render faster by changing their scenes to use other materials that were still realistic but less resource intensive. 

However, the main value of the buckets is for developers.

nonesuch00

Serene Night said:

I could really use this. I'm running into long render times for certain scenes and content and knowing what is hogging my computers resources would be useful

They have all the information already to do this so maybe it is something they will make, I don't know, in DAZ 5?

wolf359

"The buckets would directly show them resource intensive surfaces and they could develop and adapt their scenes to render faster by changing their scenes to use other materials that were still realistic but less resource intensive. 
However, the main value of the buckets is for developers."

I agree completely !!
This would be a valuable developers tool
and would result in much more "pre-optimized" content as opposed
to the utterly absurd 4x textures being used  in much content today.

 

 

" Nvidia would be wise to use DAZ Studio as one of it's suite of programs for testing and improving their iRay renderer. It is free and used extensively."

Hmm  sadly Nvidia seems more interested in selling you more powerful Brute force Hardware than providing algorithums to help you identify hardware intentsive scene elements that might lalow you to use lesser hardware options and get good fast results.
it would be nice if DAZ inc made such a bucket console for its  material developers since Iray is the future of Daz studio. 

Daywalker Designs

The key issue is that PAs don't know how buyers are going to use the content, and thus can't reasonably include textures for every possible use. And to a degree we already have access to the information the OP wants the suggested addition to find, if we are running the latest version of DAZ Studio.

1) Textures are the number one VRAM hog.

2) Geometry is number two.

How do we deal with the texture issue? Reduced resolution is fine in some cases, but not all. Close in shots need any exposed surfaces to have the full resolution texture if we want to see the details as intended by the PA. Anything not directly visible can be hidden or use lower resolution textures.