Will be supported 3ds max's native shaders (maps, materials etc.) by GPU and if "yes" - when?
Maybe, if it's something that's useful to all Arnold users. No ETA.
No. However, we're open about considering translating those that users will really really need.
Please no 🙂
All legacy initiatives must be phazed out, systematically.
And if a specific map needs to be ported, first look at OSL then Arnold code. No recompile of the ancient maps 🙂
Which legacy shaders are crucial to you from the legacy node set that would make you want to do that? explain them all if multiple.
Hmm.... I can understand the need to move forward and not waste developer time on legacy stuff. But at the same time, we should have feature parity between CPU and GPU rendering. It's no good if the user switches to GPU and the render suddenly breaks.
Great work, guys, I'm loving what you've done with MaxToA 3.0.
I think it was a mistake to start to partially support the legacy maps, like normal map and bitmap loader, it gives users initiative to make bonkers shader systems that are poluted.
So I will actually ask to have the already maps supported, removed again, to clean up.
Let me explain what happened recently in the plugin code.
We have two kinds of legacy maps.
A small set (Bitmap, Particle Age, Blend, MultiSub, Physical Sun & Sky) were previously translated by plugin-specific C++ shaders. This had 3 problems: they could not render in GPU, they could not render under Linux, the exported .ass could not render if imported as procedurals into other DCCs. Solving these issues would be more complex that, instead, trying to translate them as graphs of native Arnold nodes. The translation may not be perfect (for example, not all of the Physical Sun & Sky parameters are supported). So, this is what we did for MAXtoA-3, where of course the main goal was to have these maps rendering under GPU almost seamlessly.
The other set is the hundreds of maps coming with Max, that right now can work enabling the Legacy Map flag in the rendering options. They work because of a direct call to a Max SDK function, that works only in the context of Max itself. It can't work in a kick/GPU/Linux context.
Converting these hundreds to Arnold nodes will not happen. However, if there are some that are really useful and very commonly used, we can consider the effort to translate them as we did for, say, Bitmap.
List of materials and maps that I use often -
Materials - Physical Material (supported?), Morpher, Blend, Multi/Sub Mat.
Maps - Advanced Wood (is legacy? 3ds max 2019 :), blended box mapping (more options than Arny's Triplanar - 2018), Substance (plug from Allegorithmic), Max's sun and sky (2017), MultiTile (2018), Noise, Tile, Normal Bump, Shape Map, Text Map, Texture Object Mask, Vector Map (2018), Composite, Color Correction, Vertex Color.
@Boris Kulagin I made a new post since a reply is restricted to 600 characters.
What we already got via OSL or Arnold from your list:
- Noises impossible to make with old map, including bercon maps is possible to make with OSL and Arnold shaders.
- Vector map, we can further manipulate vectors that are impossible to do with legacy system.
- Color correct from Arnold is better than Max legacy CC, we also have CC nodes in OSL, we can integrate any color correction algo ever invented easily to expand the utility set.
- Vertex color, we dont even need that map, vertex colors are data channels that can be called directly as floats or vector/color at any point you want to do so with User data nodes, or OSL code or OSL UVW map channel set to 0.
-Composit map exsists for both OSL and Arnold, OSL composit map can be expanded its no problem to have a stack of shaders that feed.
- Tile/multitile, with 2020 we have Simple tiles OSL, we can also extend it to create any tile pattern you like, so way more flexible.
- Normal bump, I have written several Normal shaders for OSL, Arnold handles normal bump as well, we can do anything you want with OSL much more than the legacy system can give on the normal account.
- Triplanar, we can build OSL triplanar blends that are more advanced, technically the legacy one does nothing we cant do in other ways.
- Advanced wood cant be ported to open source code since it utilizes a closed set of functions autodesk wont let go out to free. We have already compiled several Wood OSL shaders, so its possible to let go, maybe the advanced wood shader can even be free, I dont know.
So that leaves substance, shape map, text map, texture object mask.
Some external loader for substance, yes makes sense.
The 3 others makes calls to mesh and other things, I would like to see the numbers of people using these 3 maps on a regular basis and then evaluate if a different workflow can be made.
So its not a whole lot actually.
On the other side, by dropping legacy maps you gain SIGNIFICANT pipeline benefits, and you also gain access to a far broader feature selection especially with OSL.
Multi-tile = UDIM 🙂 Have MAXtoA self support for this?
And finally - if devs cannot/dont want support "Legacy" (1 - 3 years old 🙂 things - please create powerfull convertor. When I trying existing script first time - I cried for 10 minutes.
The age of the maps is not the problem, its the format under which they have been developed that is the problem.
Both Arnold and OSL supports UDIM tokens.
Well, I will not remind now about the reports that "we made a new API, which allows you to easily use the Max's maps and materials in any renderers, etc." I see that everything is translated into OSL, and that is good. But... When I tried to use the Shape Map for masks on the landscape (roads etc.), I fell in love with it. No need to think about resolution, you can always correct the map in place. I don’t know how many people use it in their works, probably a little, just because they don’t know about it 🙂 Similarly, Vector Map and Text Map. Is the realization of these maps a big problem?
I have put shape map and text map on review list, potential OSL.
vector map loads vector files, so would have to be an Arnold shader for now.
Before writing about OSL, did you test the performance of these maps? They are INCREDIBLY slow, this is a pretty obvious reason not to use them unless absolutely necessary. There is a wonderful map that has no analogue Advanced wood. In the end, it’s already time to make the map of Arnold in the viewport, because this is the stone age
It's not correct OSL is slow, on the contrary.
I have written many shaders, and I have fluid realtime 30->60 FPS in the viewport rendering particles, volume effects, fractals, you name it.
Can't find what you're looking for? Ask the community or share your knowledge.