Indigo Renderer Forum

Hello all,

Here is a list of a humble reqeuest to implement in next SDK release. I'm posting it here, so other users could share their opinion.

• Add blocking rendering sequence methods:

  Code: Select all

  IndResult Renderer::Render();
  bool ToneMapper::Tone();
  

  Rationale:
  MAX is a multithreaded application and it seems IndigoSDK sometimes might be using a wrong thread to work on. Also, there's a number of tasks that don't need (or even won't allow) interactive feedback, like generating material thumbnails. In such tasks speed is most important and putting host application to sleep is just stealing some time.
  Note:
  Filling message buffer might be redundant in such case.
• Implement matrix 4x4 (or Matrix3 + Position) Keyframe definition such as:

  Code: Select all

  MatrixKeyframe( double time_, const Matrix4 &matrix_ ); 
  

  Rationale:
  Right now keyframes don't hold scaling term, which is stored in frame constant rotation matrix. This leads to naming confusion and rotation data duplication. Also internal matrix composition (testing) might be avoided with MatrixKeyframe (not to mention matrix decomposition in host application just to comply). From my experience linear interpolation of matrix values gives proper results on subframe basis (since most slerp functions use linear interpolation for such values anyway) and on rapid motion subsampling will suffice (also a problem of rotation greater than Pi is avoided)
• Add additional rendering layers (in order of importance):
  Alpha - it's already implemented though as a seperate mode. Also it would be required so refractive materials could return alpha of background (might be an option).
  Object/Material Mask - it is a layer that holds nonzero values only for points of light path that belong to specific object/material set (unique ID set in general). There might be an option just to consider first camera hits. For file storage optimization it's common to output such pass as RGB image where each color channel is one pass (it's implied all three sets are mutually exclusive)
  ZDepth - it's (normalized using parameter or not) length of first camera ray hit.
  Reflection/Refraction - these are seperate and are values that come from reflection, refraction terms accordingly.
  Direct/Indirect Light - should be self-explanatory
  Diffuse/Specular - should be self-explanatory
• Allow scene manipulation, without regenerating the whole scene tree after it was finalized. Rendering buffers should be affected as well.
  Rationale:
  For animation and realtime purposes it's important to allow such scenario:

  Code: Select all

  init_renderer();
  build_scene();
  render();
  
  update_node( some_node );
  remove_node( some_node );
  add_node( some_node );
  
  update_scene();
  render();
  {...}
  render()
  free_renderer();
  

• used_materials property in mesh seems redundant and is kind of a performance burden. Could it be removed?

Hope it makes sense. Drop me line, if something is not clear.
Thanks,
Jake

Hello,

Here's a list of some less important features I hope could be implemented in feature.

1. Render time modifications of light layers
2. Deformation blur for topology constant meshes - vertex and normal, optionally UV data could be specified on sub frame basis (predefined amount of samples)
3. IOR as mappable parameter
4. keyframe data on other parameters like camera lens_radius, lens_dist, blend_amount and so on
5. Custom modules loaded as external plugins, mainly for custom maps/shaders. I would turn ISL and textures into such modules, which might be loaded on demand. Also I would recommend considering OpenImageIO for textures management - it has caching and mip-mapping systems already implemented atop of broad range of supported formats.

Thanks,
Jake

Hi Jakub,
In answer to your requests:

* Add blocking rendering sequence methods: I think you can implement this yourself with a while loop, e.g.
* Implement matrix 4x4 (or Matrix3 + Position) Keyframe definition:
The big question here is how to do interpolation between the matrix keyframes. Simply interpolating matrix elements would result in effects such as an interpolation between two orthogonal matrices resulting in a non-orthogonal matrix. Also, Indigo sometimes needs the inverse matrix (or to multiply a vector with the inverse matrix), which is time consuming to compute from an arbitrary matrix. I'm not sure what the best solution here is.

* Render layers:
Since this is essential for VFX work, we will try to implement this stuff.

* Allow scene manipulation, without regenerating the whole scene tree after it was finalized:
Will do. This requires a bit of work to change the scene graph internal data structures to allow for faster child removal. This work is already underway however.

Thanks for the feedback!

Hi Nick,

Thanks for your reply.

• * Add blocking rendering sequence methods: I think you can implement this yourself with a while loop

  It's not really what I'm looking for. It's still suffering from performance penalty and is vulnerable to threading issues. I'm using this workaround already anyway. What I'm looking for is a method that is just before thread workers dispatch for rendering and tonemapping (btw tonemapping is single threaded, right?). This is intended for small thumbnails creation so time spent waiting is considerable.
  
  Also, while on this subject I would like to ask for a simple direct light rendering mode (might be available only from SDK). Thanks
• Matrix 4x4 - I'm familiar with your concerns, yet I can assure you that linear matrix interpolation will just do fine (it's up to user to keep it sane). I've written an animation exchange system where I've implemented various interpolation methods for matrix like Bezier or Hermite (Catmull-Rom), however simple linear did great job taken even to extreme.
  I think you could compute inverse matrices for each keyframe on object preparation and use interpolated inverse matrix where needed with minimal computation penalty. Or is there something else I'm missing?
• I'm glad about layers. You might stick to ordering as importance list. Also I'm quite confident arch-vis artists will welcome such feature.
• Could you shed some light on application of light layer via SDK, how should it be controlled. Is it LayerSetting?. Would changes to this object affect rendering?

Thanks for the feedback. Have you got some thoughts about request form second post?
Thanks again,
Jake

subpixel wrote:Hello,

Here's a list of some less important features I hope could be implemented in feature.

1. Render time modifications of light layers
2. Deformation blur for topology constant meshes - vertex and normal, optionally UV data could be specified on sub frame basis (predefined amount of samples)
3. IOR as mappable parameter
4. keyframe data on other parameters like camera lens_radius, lens_dist, blend_amount and so on
5. Custom modules loaded as external plugins, mainly for custom maps/shaders. I would turn ISL and textures into such modules, which might be loaded on demand. Also I would recommend considering OpenImageIO for textures management - it has caching and mip-mapping systems already implemented atop of broad range of supported formats.

Thanks,
Jake

Hi Jake,
Render time modifications of light layers: This will be possible, also direct access to each layer will be possible at some point.

Deformation blur for topology constant meshes - vertex and normal, optionally UV data could be specified on sub frame basis (predefined amount of samples):
As this is important for VFX, we will implement this at some point.

IOR as mappable parameter: Do you mean phong IOR or specular IOR?

keyframe data on other parameters like camera lens_radius, lens_dist, blend_amount and so on:
Why are keyframes needed for this?

Custom modules loaded as external plugins: The main problem with using binary modules (dlls etc..) that I see is that it won't be possible to execute such code on the GPU. I would prefer such stuff to be written in ISL which may execute on the GPU in future.

OpenImageIO we will take a look at at some point.

Hi again,

Thanks for information.
About IOR I've meant both
About keyframe data: pretty much every parameter should be animatable (maybe boolean parameters wouldn't make sense), however camera parameters are most important, there's a number of applications like rapid changes of focal or FOV in live action or it might be used for timelapses (here position of sun might be important).

I see your point with GPU constraint (thought I'm not an expert in this field). My motiviation is that it would enable to port nearly all maps/shaders available within max efficiently without baking as well as atmosphere objects (like fumes). It would make sense, even if it wouldn't allow GPU execution (on most of renderfarms nodes hasn't considerable GPU)

Also one more request/question: Would you plan to implement a hair primitive any time soon?

Again thanks,
Jake