[eric nixon]

I need to use native C4d displacement (its being weighted by animated vertex maps) EDIT: I just found the restriction tag in c4d for linking vertexmaps to the displacement deformer, so that solves my issue for now...I never realised that you could apply tags to deformers

When the current plugin translates native c4d displacement, it gives it a subdivision value of 16 by default, and there is no way to change that (insanely high) value. That seems like an oversight?
Obviously it would be great if the plugin could pick up the subdiv value from c4d's material settings, but if thats not possible a lower default like 3 would be usable, because then I can control the disp resolution by manually subdividing the geo beforehand.

When it comes to animated materials in general, C4D has an existing wealth of resources and techniques to create interactive materials. I wish for a connection between the maxwell material, and some animated c4d material/s. So my idea is that you would apply both materials to an object. The c4d material could just have 1 channel activated (colour channel for example) and the maxwell material could reference that channels data at export (via outputted maps) as a bsdf/layer weightmap for example.

[eric nixon]

ARGHH. now I get a feedback effect where the displacement is influencing the vertexmap (which cannot be cached) the effect looks very cool (like boiling lava) but its not desired

I think I need to do the disp in a c4d material after all.

[eric nixon]

I found a tutorial from yader with a little bit of expresso to duplicate the vertexmap to avoid feedback loop, works well sry off topic but seemed interesting.

btw, Im using the codevonc pointinfluence plugin, c4d tension tag has a similar funtionality.

[JDHill]

When the current plugin translates native c4d displacement, it gives it a subdivision value of 16 by default, and there is no way to change that (insanely high) value. That seems like an oversight?
Obviously it would be great if the plugin could pick up the subdiv value from c4d's material settings, but if thats not possible a lower default like 3 would be usable, because then I can control the disp resolution by manually subdividing the geo beforehand.

I'll change the default to 5.0, to match MXED (apparently it changed without my noticing). However, the idea that 16.0 is high only highlights the inherent problem: a given value can be considered high or low only with respect to some specific geometry. As such, I choose to leave the default value, and instead suggest that you control subdivision directly on a per-object basis, by using the Object Properties tag. Under the hood, subdivision in displacement is done using the same mechanism, but rather than being able to control it on a per-object basis, it gets applied to every object using the material, and that problem would still occur, if we took the value from the Cinema material. Personally, I don't think subdivision should be tied to materials, at all -- displacement should simply displace whatever geometry it is applied to, whether that geometry has been subdivided or not.

[eric nixon]

Thank you, I forgot about object properties tag.

I still think 5 would be a better default, less 'out-of ram' situations that way. (16, when applied to this coffetable crashes my 48gb workstation - sorry to labour the point)

[JDHill]

Probably, I should set it to zero, and say that you simply have to do the subdivision with obj props. Because, whether it's 5, 16, 100, whatever, it's very likely to be wrong for what you happen to be working on. I have to check if there is any problem with that, but I think it should work fine.

[eric nixon]

Just to say, I tried obj properties but it still gets the disp-subdivision and then subdivided again (but with rounded corners).. but also the 'vertexmap X noise' layer doesn't get translated properly into a map at export, its all weird stripey looking even when its set to uv mapping.

Anyhow I think the workflow using geo in the viewport is fine for this task. I can see that getting all c4d material possibilties to translate is unrealsitic. We need to use the vertexmaps in mxed directly.



(offtopic) This is an image of geo version with disp deformer + extra random effector set to polys driven by the live vertex map..

[eric nixon]

Hi JD, I picked up the new plugin, that was quick.

I wondered if you had seen this video, at 30 minutes in he talks about plugin integration with c4d via a 'user data shader'.

https://www.youtube.com/watch?v=sxNf7Ei ... 818.014385

[JDHill]

I was actually building it when you posted, so you caught me at the right time. On the video, I'm not sure what you're getting at, but if I understand correctly, that is just a way of having the plugin connect arbitrary data in Cinema with a shader in the render engine, a concept for which there is currently no analog in Maxwell (for example, driving a reflectance 0 color from arbitrary data at render time -- per-vertex data, or a random value based on object name, etc, etc -- such that it could render using a different value at each point on the mesh).

[eric nixon]

Yes maxwell itself would need some changes for this to work, so maybe out of your hands.. but pass on the sentiments if you can. I can remember Juan saying that support for animation would be a feature of maxwell 3, but that hasnt happened

C4D-maxwell integration is not as good as other render engines, especially for animation that is essentially my point,..... I feel like the scope of the plugins integration is held back by keeping it similar to the level of the other maxwell plugins.

I am not a fan of nodes for materials though, which is one reason I have little interest in arnold or octane.

[JDHill]

Well (as I see you wrote in an edit), a plugin can only integrate what actually exists in the engine, and currently, this type of functionality doesn't. Say you want to randomize the color of each leaf on a tree; aside from workarounds like using a huge map and randomizing UV coords, the fact is that you are going to need to make a separate material for each leaf -- literally, you need thousands of MXMs, and this has nothing to do with which plugin you happen to be using. To get around that, the engine needs to be able to do things it currently doesn't; it could get the material for a given mesh, and then modify it according to some data stored on that mesh; or, it could modify the material uniquely for literally every ray that encounters the mesh. But, that is not something that a plugin can help you with, unless it is first supported by the engine.

Once you get there, though, there's not much way around involving nodes; for well-known scenarios, helpers can be set up, and UIs can be built, but very often, you'll come at a difficult scenario with a solution that is either too rare to warrant a custom UI, or simply too novel to have been predicted in the first place.

[eric nixon]

Well as long as the nodes are only used when needed thats fine.

I see in arnold that to build a (non-animated) material with more than one bsdf you need to use nodes. clickety click click drag click slip fk.. wrong end of shitty stick IMO.