Community
Arnold General Rendering Forum
abbrechen
Suchergebnisse werden angezeigt für 
Anzeigen  nur  | Stattdessen suchen nach 
Meintest du: 

Advanced Render Log Info

8 ANTWORTEN 8
GELÖST
Antworten
Nachricht 1 von 9
Andrew_Wilkins1
893 Aufrufe, 8 Antworten

Advanced Render Log Info

Hi everyone,

I'd really like to find more in-depth technical information on render logs, I was wondering if that info is available anywhere? Really quite interested in the "OpenImageIO Texture statistics" for example.

I've found this doc, but it unfortunately doesn't go into much detail.
https://docs.arnoldrenderer.com/display/ARP/How+to+Read+a+Render+Log

The main goal is to be able to tech check assets / spot unhealthy assets and shots in terms of render optimizations etc.

Edit:
"OpenImageIO ImageCache statistics"

  1. File I/O time -> Are higher/lower times something to look out for?
    -
  2. Redundant Reads vs Cache Memory -> If redundant reads are high, should the cache size be increased for better performance?
    -
  3. Tiles -> I'm guessing the higher values are more of the tiles being seen in shot? Is a higher or lower value something to keep in mind for any reason?
    -
  4. Total pixel data size VS Total actual file size, the pixel data generally being higher than actual file size?
    ---- Other: ----
  5. The warnings "displaced objects have very poor bounds. This can severely affect ray tracing performance." and "Scene creation was a significant amount of total time (57%). Consider optimizing this process first." -> Something to worry about?
    -
  6. The amount of "Shadow" ray counts generally always being one of the highest value, is the a normal occurrence?
    shadow 7205071109 (3474.67, 345.41) ( 80.58%) ( 0.90) ( 9)
    -
  7. What does fairly high "light filter" values/percentage mean, in terms of Shader Calls? Is it that a lot of light decays and gobo's where used? What sort of render impact can those have?
    | light_filter 12533780797 ( 6044.45, 600.86) ( 32.26%)
    -
  8. In terms of .ass file caches I'm assuming that the higher percentage of "reused" caches would mean increased performance and lower ram usage?
    | unique (loaded from disk) 283 (5.93%)
    | reused (found in cache) 4493 (94.07%)


Thanks very much,
Andrew

Tags (2)
Beschriftungen (2)
8 ANTWORTEN 8
Nachricht 2 von 9
Stephen.Blair
als Antwort auf: Andrew_Wilkins1

No, people usually ask about specific parts of the log, so there's answers posted in different parts of the user community. There's no "advanced render log" documentation tucked away somewhere.



// Stephen Blair
// Arnold Renderer Support
Nachricht 3 von 9
Andrew_Wilkins1
als Antwort auf: Stephen.Blair

Okay, thank you Stephen.

Nachricht 4 von 9
Stephen.Blair
als Antwort auf: Andrew_Wilkins1


@Andrew Wilkins

But please ask and I'll do my best to get some answers...



// Stephen Blair
// Arnold Renderer Support
Nachricht 5 von 9
Andrew_Wilkins1
als Antwort auf: Stephen.Blair

I've edtited the main post with a couple more specific questions. For when you get a spare moment. :zwinkerndes_Gesicht:

Nachricht 6 von 9
Stephen.Blair
als Antwort auf: Andrew_Wilkins1

File I/O time

Large I/O times may indicate a network problem eg very slow transfer rates



// Stephen Blair
// Arnold Renderer Support
Nachricht 7 von 9
Stephen.Blair
als Antwort auf: Andrew_Wilkins1

Redundant Reads vs Cache Memory

If redundant reads is large, you'll probably benefit from a larger cache. Redundant reads means tiles are flushed from the cache, and then read back in later.



// Stephen Blair
// Arnold Renderer Support
Nachricht 8 von 9
Stephen.Blair
als Antwort auf: Andrew_Wilkins1

Total pixel data size VS Total actual file size

OIIO (the texture cache) holds uncompressed image data, while files on disk have compressed iamge data



// Stephen Blair
// Arnold Renderer Support
Nachricht 9 von 9
Stephen.Blair
als Antwort auf: Andrew_Wilkins1

Tiles

If the cache is too small, you'll see more tiles being loaded, because the same tiles are loaded over and over. Check the mip counts:

|   Top files by bytes read:
|     1    265.7 MB ( 2.3%)  8192x8192x4.f32  example.tx MIP-COUNT [1523,1720,671,234,75,17,4,1,1,1,1,1,1,1]

If see huge numbers of reads at the higher mip levels (eg 1523 above for the 8192x8192 mip map level) then the cache is probably too smal



// Stephen Blair
// Arnold Renderer Support

Sie finden nicht, was Sie suchen? Fragen Sie die Community oder teilen Sie Ihr Wissen mit anderen.

In Foren veröffentlichen  

Autodesk Design & Make Report