Public alpha release of IndigoMax

[Javadevil]

I look forward to trying IndigoMax.

How are you going to setup physical sky ? will it have its own light in the viewport ? to move around ?
On the list of things, wheres the environment ? really need the use of HDRI lighting for testing

Its good to see a real plugin being created.

cheers

[kdarius]

Hey subpixel,

just letting you know I download the new version and am able to get it to render.

Thank you,
Darius Kirschner

[subpixel]

How are you going to setup physical sky ? will it have its own light in the viewport ? to move around ? On the list of things, wheres the environment ?

Javadevil: There's going to be a Indigo background map shader added, which will incorporate (using weighted map) all background layers like: spectrum background, physical sky and HDRI light. For now sun position will be set with selected light object.
I'll release it with some new features by the end of the week.

kdarius: Thanks for report. I'm glad it's working for you.

Cheers,

[Javadevil]

Look forward to it,
Is there any info on the spectral background map ? I had a look under features and couldn't see any specifics.

cheers

[subpixel]

Look forward to it,
Is there any info on the spectral background map ? I had a look under features and couldn't see any specifics.

Well, it's nothing new. In this release there's going to be a renewed Spectrum Map, which will allow spectrum values also as background parameter. For now there will be supported spectrum types: blackbody, RGB, peak, and uniform. Tabulated will need some additional UI, but is planned in final release.

[subpixel]

Hello all,

It took a bit longer than anticipated, yet I've finished Spectrum Map and Environment Map with some other enhancements. However there seems to be a bug in IndigoSDK with background read from texture, which pretty much makes it unusable. I have reported it already and I waiting for solution.

Meanwhile, following fused initiative (who follows Whaats) I would like to gather a whishlist for first release. I will consider only features reported by multiple users.

Cheers,

[ENSLAVER]

An option to work within max while the scene is being rendered -or- an option to export and render in indigo, old style. Rendering while modeling/scene editing became a huge advantage/time saver to me over things like vray where the buffer is in use and max is inaccessible. The use of the max buffer is a great idea if you can enable all the realtime controls indigo has implemented (like vrayRT) but I would imagine that would take a lot of work and be almost impossible (ie moving the camera in the scene moves the camera in the max buffer/updates). I don't want the critique to sound too harsh but the time could be used to work on things that are more useful overall. I would love if people can point out the advantages of using the max buffer because I want to believe! Subpixel can let me know what the plans for future integration will be (how integrated will it be possible to make it?).

I've posted previously that my ideal workflow would be to have an option/button in max, where max grabs the changed information into the max scene from indigo (camera position and settings, sun location, materials, etc). It seems more feasible than trying to totally integrate all the realtime features (that we've come to love) back into max.

A proxy system, and/or object. Proxy stuff. It would be awesome to have a proxy object that you can paint/scatter/etc using already written max scripts and tools (groundwiz, particles, multiscatter, advanced painter, etc). Perhaps later an indigo specific proxy system that has more support for randomizing colours/scale/density/maps/placement/etc. (Suv's last proxy system was pretty awesome, just lacked the object)

Integrated ISL like in cindigo (Posted by DCM in another thread).

Particles w/motion blur.

Should report an error if the resolution is over 0.7 MP instead of not rendering.

Objects with "renderable" in object properties unticked shouldn't be rendered.

Multi/Sub-object textures currently crash IndigoMax

Indigo logo at the bottom right instead of the tiled watermark would be cool.

[subpixel]

Hello Enslaver,

Nice to hear from you and thank you for your insights.
You're quite right about workflow suggestion. This issue was already raised and I have already some ideas, how to solve it. However there need to be some changes introduced to Indigo SDK, so I'm waiting for Ono response now.
I plan four main workflow options:

• regular rendering (blocking system yet most effective - fastest rendering). All network renderings fallback to this one. As an option it can contain controls for adjustments while rendering.
• scene freeze (non-blocking system). It will allow further work, while rendering. All changes to scene will be disregarded. As an option it can contain controls for adjustments while rendering. This mode is for single frame rendering only, animations need regular mode.
• active shade (non-blocking interactive mode). It will track all changes to the scene and restart rendering when changes are made to the scene (changing camera, adding/removing objects, changing materials and so on). It's only for interactive sessions, in fact it's not a real rendering.
• export to igs file. There might be an option to render exported file. It's already implemented in debug build, yet there is a number of issues I've reported to Glare, which corrupt exported scene. Once solved it might be published.

Also for performance reasons there will be an option to hold geometry data, so iterative renders won't suffer from redundant processing.

You're right that implementing controls to render frame buffer is a considerable amount of work (as any other GUI in win32), yet it's not that bad. I believe it's manageable and will follow that path (though i'ts not top priority atm).

About advantages of current solution I hope some other could share their opinion, yet I'm not sure if everyone grasp the main difference here. It's not just a difference between using frame buffer or not. There is a huge difference between real renderer and exporter. Renderer can use all host application resources and render-time information, as such it allows data caching and interactive feedback. Also it allows Max default workflow actions like saving files, animations, net-rendering, non-UI max sessions and MAXscript access. I know that right now it might seem like a drawback, hope to prove it otherwise. It's not a bug, it's a feature

About your ideal workflow, grabbing data from external process might be harder and potentially unstable than implementation of additional controls into max. Yet, if Glare will implement such interface, I'd be happy to implement it.

A proxy object is already on my todo list among other native objects like camera and light. Particles are atm low priority.

Thank you for crash report with multi/sub, I haven't addressed this matter yet.

Indigo logo comes from Indigo core, I cannot alter it. However, all debug and alpha builds have forced watermarking.

Again thank you for your feedback and suggestions. At the moment stability is my main concern, however keep in mind that some of instability issues are raised by Indigo SDK alone, yet it's a great piece of software to work with. Please don't expect first release will implement all features Maxigo had. It was a project developed for a couple of years. I'm not trying to reinvent the wheel, but I need to make it from ground up, so issues might be solved differently. I encourage all to share their opinions.

Cheers,
Jake

[ENSLAVER]

Hello Enslaver,

Nice to hear from you and thank you for your insights.
You're quite right about workflow suggestion. This issue was already raised and I have already some ideas, how to solve it. However there need to be some changes introduced to Indigo SDK, so I'm waiting for Ono response now.
I plan four main workflow options:

• regular rendering (blocking system yet most effective - fastest rendering). All network renderings fallback to this one. As an option it can contain controls for adjustments while rendering.
• scene freeze (non-blocking system). It will allow further work, while rendering. All changes to scene will be disregarded. As an option it can contain controls for adjustments while rendering. This mode is for single frame rendering only, animations need regular mode.
• active shade (non-blocking interactive mode). It will track all changes to the scene and restart rendering when changes are made to the scene (changing camera, adding/removing objects, changing materials and so on). It's only for interactive sessions, in fact it's not a real rendering.
• export to igs file. There might be an option to render exported file. It's already implemented in debug build, yet there is a number of issues I've reported to Glare, which corrupt exported scene. Once solved it might be published.

Also for performance reasons there will be an option to hold geometry data, so iterative renders won't suffer from redundant processing.

You're right that implementing controls to render frame buffer is a considerable amount of work (as any other GUI in win32), yet it's not that bad. I believe it's manageable and will follow that path (though i'ts not top priority atm).

About advantages of current solution I hope some other could share their opinion, yet I'm not sure if everyone grasp the main difference here. It's not just a difference between using frame buffer or not. There is a huge difference between real renderer and exporter. Renderer can use all host application resources and render-time information, as such it allows data caching and interactive feedback. Also it allows Max default workflow actions like saving files, animations, net-rendering, non-UI max sessions and MAXscript access. I know that right now it might seem like a drawback, hope to prove it otherwise. It's not a bug, it's a feature

About your ideal workflow, grabbing data from external process might be harder and potentially unstable than implementation of additional controls into max. Yet, if Glare will implement such interface, I'd be happy to implement it.

A proxy object is already on my todo list among other native objects like camera and light. Particles are atm low priority.

Thank you for crash report with multi/sub, I haven't addressed this matter yet.

Indigo logo comes from Indigo core, I cannot alter it. However, all debug and alpha builds have forced watermarking.

Again thank you for your feedback and suggestions. At the moment stability is my main concern, however keep in mind that some of instability issues are raised by Indigo SDK alone, yet it's a great piece of software to work with. Please don't expect first release will implement all features Maxigo had. It was a project developed for a couple of years. I'm not trying to reinvent the wheel, but I need to make it from ground up, so issues might be solved differently. I encourage all to share their opinions.

Cheers,
Jake

Awesome. You have some big plans, it will definitely be something to look forward to Your solutions make my "ideal workflow" seem outdated. If we can do all that stuff in max it will be amazing. Because indigo is built around power, being able to harness more of it by running it inside of max will be great.

I like your approach though I don't envy your workload =P The regular rendering+activeshade not only covers my concerns, it has me excited.

[subpixel]

Hello all,

Here's another update. Apart from some minor bugfixes this version brings:

• Spectrum Map and Environment Map
• Normal data
• Multi material support

Notes:

• There's a bug within Indigo SDK with textured environment material, so this option is disabled in Environment Map by design.
• Rendering mode combo as well as geometry cache are not functional in this build

As always, bug reports, comments and suggestions are most welcome.

Cheers,
Jake

[ENSLAVER]

Hmmm I seem to crash when I add a cube to the scene (teapots are fine on their own)

Oddly it crashed with just a geosphere, but not when I started with a teapot then added a geosphere. Some other objects exhibiting the same behaviour (cylinders and spheres crashing, a torus renders though)

multi/subobject crashes max almost as soon as I add it (trying to render them all at once?)

max 2012 x64 on win7 x64 - not sure what service pack/updates I have in for it (been a few) lots of plugins etc.

Apart from that it's looking awesome

An added request I guess, would it be possible to have the standard max environment less powerful? Or the standard max lights more powerful? (so you don't have to set the max light multiplier to 9999 to be on par with the environment at 128,128,128)

Any idea when there will be a GPU checkbox? =P

Probably more stuff, it's Australia day, everyone is celebrating and I only have a limited time to test =(

[ENSLAVER]

Seems to be having an issue with some polys/normals/backfaces?
Teapot removed from another teapot using proboolean (teapots had "capped holes" modifiers before proboolean):

[subpixel]

Hi Enslaver,

Thank you very much for bug reports. It was late already and I haven't tested it thoroughly. My intuition would indicate crashes are related with multi materials.
If this is a case a quick solution would be to convert it to poly and assign a material or all material ids to 1. Sorry, but right now I cannot test it myself.

The second case (boolean teapot) might be a more subtle bug, however you might this: retriangulate mesh with subdivide modifier (so you'd end up with all triangles) and collapse it to poly.

Again thank you very much for your time and feedback. I'll get to it asap.

Cheers,
Jake

[subpixel]

Concerning light intensity balance, this matter is open and I hope for some advice from more experienced users.

However I'm almost happy with environment light strength, since with linear 1.0 tonemapping I get almost same color as on color picker.

Anyway, this matter need to wait a bit since there need to be implemented Emission Scale parameter first (right now it's default).
All suggestions are most welcome.

Thanks,
Jake

[ENSLAVER]

Hi Enslaver,

Thank you very much for bug reports. It was late already and I haven't tested it thoroughly. My intuition would indicate crashes are related with multi materials.
If this is a case a quick solution would be to convert it to poly and assign a material or all material ids to 1. Sorry, but right now I cannot test it myself.

The second case (boolean teapot) might be a more subtle bug, however you might this: retriangulate mesh with subdivide modifier (so you'd end up with all triangles) and collapse it to poly.

Again thank you very much for your time and feedback. I'll get to it asap.

Cheers,
Jake

You are correct, when I added a cube/cylinder/etc and apply a material (no need to convert to poly) they rendered fine without crashing, only those without a material applied would crash.

The boolean teapot was fixed (left) using Tesselate (4 sided, face center, iterations 1, results in all triangles). The subdivision modifier was used on the right... lol