Indigo Renderer 3.4.2

[lycium]

Hmmm, I guess it's possible, but the commandline isn't too much work, surely? Just a bit of right-clicking to copy path, pasting into a command window... it's not a very common operation either.

[pixie]

Hmmm, I guess it's possible, but the commandline isn't too much work, surely? Just a bit of right-clicking to copy path, pasting into a command window... it's not a very common operation either.

Workflow wise it's quite a drag... merging igi where it keeps poping up for the name of the files coulde an easy solution, down in the tools menu perhaps...

[CTZn]

Exporters can also handle IGI merging.

[Voytech]

Hmmm, I guess it's possible, but the commandline isn't too much work, surely? Just a bit of right-clicking to copy path, pasting into a command window... it's not a very common operation either.

I'm on OS X so I'm not sure how to do that. I was thinking of a command in the File menu of Indigo which would open an "open file" window for the first and then second IGI.

[MattMR2]

Hi all,

Just somes questions and ideas :

- Do you planed to add bi-dir and MLT to gpu/hybrid ?
- Now you developped parametric surface, Do you planed to export Blender fur (or shave and haircut from Cinema 4D, as well as strands too) using the parametric surfaces ?
- I not found answer in help, but have you an idea how to setup correctly an animation with Indigo, cause the modifications done in the first frames not be report to other frames, and is a brake for using indigo in animation production (indigo is close too Arnold render).
- It'll be good to enabled a param to hide mesh light from camera, to emitting light without have the mesh source in the picture (more production orientation).
- it's also difficult to fine tuning light then using linear and camera tonemappers (many time in camera tonemapping it's overburn or just black... maybe I missed something from blender).
- There is a way to modify the IBL texture and orientation or mode (from texture to constant color) from inside Indigo ? if not, will be good to have it.
- I think, a possibility to have premultiplied alpha in the rendering viewport and directly in the picture will be a good idea (in this mode IBL is hide but still lighting scene)
- To have other data like Z-depth too
- To have a special shader that get reflection, GI bounce and shadows upon an alpha will be good for compositing process (like in Arion)
- Possibility (and I think it's not hard at all to have it) to save an 32 float exr but with keeping tonemapping done before, with camera or Reinhard tonemapper. As still float, you not have plages color in composting and keep the tonemapping.
- a way to decide to disable some features from the engine, like no caustic, and a way to have max depth (production oriented features).
- enabled multi passes exr, and also multipasses in Indigo (production oriented features).
- I saw somewhere in the forum, you tried volumetric smoke, did you planed to implemented it, and it'll be possible to support Blender smoke caches and data like color temperature and co ?

note : SSS meduim not have the same result in GPU than bi-dir and mlt, like no SSS at all.

Best Regards,

Matt

[solarray]

The bug I encountered in 3.2.2 is still alive:

In the Texture Editor a button reload texture would be nice. At the moment when a texture is loaded and i will overwrite it with a 2d app, indigo will not recognize it.

This request has been marked with an higher priority ;)

How many priority levels do you have ? :)

[CTZn]

There are three, and we use one. Here's how I concluded with that report, for it was exceptional (if not meaningless) to do otherwise:

I hope I am not overdoing it with the priority, the issue is preventing users from a common workflow.

But let's cut to the chase solarray, I am possibly getting your point. In most cases, what Indigo users expect from it's interface should instead be found within the respective exporters. That's why the GUI got little love as compared with the renderer core.

Do you want to say something around those lines or did I misinterpret your question ? I do believe that your opinion may be representative so I'm encouraging you hereby !

[solarray]

In most cases, what Indigo users expect from it's interface should instead be found within the respective exporters. That's why the GUI got little love as compared with the renderer core.

I understand the structure -> 3d app -> exporter -> renderer, and therefore seperating features/functions etc to its corresponding section to get less overlapping and therefore a clearer view.
But my concern to this missing feature was not regarding to the normal workflow like above but to such a nice implementation of a material editor like yours. When people want to work on materials they dont need any 3d app nor exporter. They only have to open indigo and start changing the settings, while they see their changes in "realtime". Thats really a powerful feature because you can be so fast, and you dont have to bother with 3d apps and exporters, waiting until export is finished and so on.
But when you creating materials you may use some 2d app from outside to make changes for your diffuse texture or other channels and you dont wont to save the changes into a new file name but you want to overwrite the excisting, but when indigo doesn't see the changes until a restart.... So there is no way to negate this feature, otherwise you will negate the whole idea of your material editor.

By the way, I tested the old standalone material editor (2.4.13) and this one recognizes and reloading a texture automatically when I change the image from outside :)

Best regards!

[solarray]

I hope I didnt misunderstood you !?

[CTZn]

Not at all solarray. I stepped out the discussion a moment to see if the suspense would cause an intervention from above :)

Any trivial the workflow you may need, it it is good to describe it to Ono and company.

Can you imagine that I requested a similar workflow one year ago ? "Render restart upon referenced file change, as an option (Live Mode)" is the title. It could be a lock attribute for parameters instead. This, with external editors in mind (image, text, ies generators and such).

I am totally with you ! The thing is, they don't implement each and every thing I am asking for, and with reasons :) My voice counts for one, and I mean neutrality before requests.

In the other hand it takes several reports before the importance of some feature request can be appreciated correctly by the developers. Thanks for the +1.

You want a smoother integration of the Indigo GUI into a mixed pipeline, if I'm making sense. In my own opinion it would be worth to think of a trade-off between exporter (SDK) and GUI editor integrations. It sounds legitimate to think of the Indigo GUI as a "blackbox" for your pipeline, pipeline wich may imply several applications bridged or not.

[CTZn]

So solarray, please rate my generalisation of your request; I am attempting to caracterize an eventual editing orientation inferring for the Indigo GUI.

External files should be reload-able and then restart the render, would you put it that way ?

@MattMR2: you have raised a lot of points, we will address them progressively :) Some may be added as requests in the Bugs and Requests sub-forum.

- Do you planed to add bi-dir and MLT to gpu/hybrid ?

This was not excluded, bidir acceleration would probably happen first then.

[MattMR2]

@CTZn : Oki thanks for the informations

[solarray]

So solarray, please rate my generalisation of your request; I am attempting to caracterize an eventual editing orientation inferring for the Indigo GUI.

External files should be reload-able and then restart the render, would you put it that way ?

Exactly what I was saying regarding images, but if its no problem extending this feature to all external file types... why not.

[CTZn]

Well let's have this fixed for textures as a starter, since it used to work as you mentionned.

Otherwise yes, I do believe that generalizing the idea would help with productivity, provided that it remains an option, wether generic or file-based. I don't know how much Ono likes the idea :)

Thanks again for your input solarray !

[lycium]

Hi Matt, sorry for the late reply!

Some quick answers...

- Do you planed to add bi-dir and MLT to gpu/hybrid ?

Bidir: Yes, and soon.
MLT: Maybe...

- Now you developped parametric surface, Do you planed to export Blender fur (or shave and haircut from Cinema 4D, as well as strands too) using the parametric surfaces ?

This isn't the usage we had in mind, and although it's maybe possible to use this for hair, it would use a ton of memory since it creates normal static mesh geometry; i.e. it's not a specialised hair/fur rendering solution.

- I not found answer in help, but have you an idea how to setup correctly an animation with Indigo, cause the modifications done in the first frames not be report to other frames, and is a brake for using indigo in animation production (indigo is close too Arnold render).

Which exporter are you using? Indigo animations are usually just a sequence of scenes rendered with a halting condition.

- It'll be good to enabled a param to hide mesh light from camera, to emitting light without have the mesh source in the picture (more production orientation).

We've had a hack for this in single-directional mode, but it's not as easy with bidir. Maybe someday, but we don't get as much demand for this compared to, say, clip planes and ortho camera support.

- it's also difficult to fine tuning light then using linear and camera tonemappers (many time in camera tonemapping it's overburn or just black... maybe I missed something from blender).

I've been meaning to add more colour/contrast control for ages... it'll be after-hours work for this, since the changes aren't so important that it warrants core dev time, but it's simple enough to warrant doing "soon" in some idle hours

- There is a way to modify the IBL texture and orientation or mode (from texture to constant color) from inside Indigo ? if not, will be good to have it.

Yeah, more environment controls are required in the UI. I'll bump this in our TODO list along with some other small related items.

- I think, a possibility to have premultiplied alpha in the rendering viewport and directly in the picture will be a good idea (in this mode IBL is hide but still lighting scene)

Sorry, I'm not sure exactly what you mean here... something like in Photoshop, where it's premultiplied against checkerboard background for visualisation?

- To have other data like Z-depth too

Agreed, we need to be able to save out more render channels generally, and Z is especially low hanging fruit.

- To have a special shader that get reflection, GI bounce and shadows upon an alpha will be good for compositing process (like in Arion)

These are trickier, and I'm not super clear on exactly what kind of output is expected; please feel free to mail some example output to support@indigorenderer.com and we'll keep it around for consideration, thanks!

- Possibility (and I think it's not hard at all to have it) to save an 32 float exr but with keeping tonemapping done before, with camera or Reinhard tonemapper. As still float, you not have plages color in composting and keep the tonemapping.

I think Indigo supports this already, as "tonemapped EXR" output.

- a way to decide to disable some features from the engine, like no caustic, and a way to have max depth (production oriented features).

Interesting idea, I'll take this up with Nick soon since we already have partial/outdated support for this in the core Max depth is already possible to set, via the <max_depth> render settings tag.

Edit: Doubtful that the no-caustic etc option will be added, we'd like to address convergence problems (e.g. due to caustic reflections) differently. No details on that yet though I'm afraid.

- enabled multi passes exr, and also multipasses in Indigo (production oriented features).

Sorry I don't know what you mean here; multi-channel, perhaps?

- I saw somewhere in the forum, you tried volumetric smoke, did you planed to implemented it, and it'll be possible to support Blender smoke caches and data like color temperature and co ?

We currently load Blender format volumes, however direct support for this in the exporter is not yet implemented.

note : SSS meduim not have the same result in GPU than bi-dir and mlt, like no SSS at all.

They should all converge to the same result eventually, because Indigo is unbiased; however, different rendering modes will have dramatically different convergence behaviour - for SSS I'd say single-directional path tracing, possibly with MLT, is the way to go (bidir can be relatively inefficient for complex volumes in which very long eye and light paths don't interact).