[JorisMX]

Most MXMs I see in the mxmgallery are pretty simple and streamlined however I'm doing a pretty tricky job atm that requiires materials with insane layer counts and multiple coatings per mxm.


I am able to render only one material at the same time. As soon as I try to render both objects together with material 1 assigned to the first obj and material 2 to the second mxcl crashes.



This is basicly my mxm tree. I have sgray jpg textures assigned to each layer as weightmaps and I have sgray jpgs driving the coating similar to gotoxys lense mapping approach.

First thing to say is that I would love to reduce the amount of layers but I simply can't.
The client requires different types of materials on one object.

any ideas?

[Maximus3D]

I don't know what to tell you to help you with this problem, but i have to say i have never seen a materialtree that crowded before i'd really like to see what that looks like rendered. If you can show it would be interesting.

/ Max

[mashium123]

...
First thing to say is that I would love to reduce the amount of layers but I simply can't.
The client requires different types of materials on one object.

any ideas?

If there's different types of mats on one object, wouldn't the obejct be splitable in it's different mat-parts?
I don't know which app you're working with, but there could be the possibility to for instance create a selection that uses one type of mat and split that off from the original object... the same with other parts of the object and so on...

[JorisMX]

Hey thanks for chiming in guys,...

Perhaps my little image is confusing. But these are 2 different materials. One for the Product itself and one for its box.
I have managed to render them together in one scene now, but I had to remove ALL coatings

I must say that there are ALOT of different materials like chrome, colored coatings, transparencies, shiny and blurry reflections going on in a single mesh.

Mesut, vielen Dank für den Tipp!

Splitting the mesh into individual parts really seems to be the best way to solve these problems and avoid overcomplicated materials....
Which of course would mean we would have to remodel some stuff.

A job like this normally starts off with some healthy R&D. Which we did...
However, looking at it now it seems kind of naive of me thinking that if I could render each item separately w/o any problems it wouldn't be too hard to just put them together.

Since the deadline is creeping up on me I guess I will have to compose these group shots with dummies using non-coated materials.

Of course if any of you have suggestions please shout out loud!

Max, unfortunately I can't post images/renderings at this point because the Product is not on the market yet. NDA yadda yadda...
It's always difficult to post about these kind of problems on the forum without revealing the products we are rendering.

[JorisMX]

Oh and btw I'm using C4D 10.5.
So I've avoided using multitextures and selections. No good experiences with that...

But I sure will try to split it up by cutting it into smaller parts.

[Bubbaloo]

I can't think of why it would crash unless you are using too many high res maps, ML, high res render, etc...

[JorisMX]

That might be it.

I just tried Mesuts suggestion but it still crashes.

I use 1200dpi 15x15 cm JPG at high compression for my maps and you are pretty right Bubba, I have about 19 maps to make the entire material...

I managed to cut down the maps per material drasticly after adding an extra plane with the product logo and the chrome parts separated from the rest.

Still no go. I have to render to about 3,5k pixels for print ...

Sigh, is there any reason why I reach maxwells limits (no pun intended) with almost every job I do?

[mashium123]

1200 dpi, 15cm * 15cm...
1200 dpi, 5,9 inch * 5,9 inch
7080px * 7080 = 50.126.400 Pixel

round about 50 Megapixel * 19 pics...

I'm not sure, 'cause I'm never sure of anything... but that's another story... , but compressed jpg will need to be decompressed at some point... won't they? I mean, the renderer will need to know the info about every single pixel that a map delievers, no?

So, if that is so... the memory thing Bubbaloo mentioned together with 3,5K & ML... seems to be most plausible. Have you tried the 64bit-command-line-technical-preview-gold-feature that this release offers?

If that's not the way to go... have you tried - just to have a look at that memory theory- to use a low-pixel version of that 19 maps?

Grüße aus B.

P.S.: When or where does it crash? Do you always use cinema-export?
Or are you trying to sort these things out in studio? So, can it be a plug-in thing?

[Mihai]

Just look at the nr of pixels the textures have, dpi has no meaning when rendering, it's just for printing purposes. Using jpg at high compression won't matter when rendering, they will still consume the same amount of memory, depending on how big they are. Plus those artifacts you get in jpg when compressing them a lot will show up in the render.

[JorisMX]

I have suffered from pixelated and low quality in fine graphic lines and text on the products I've been rendering before.

This is basicly why I increased the size. However my utter noobery seems to have caught up with me! Thanks alot for the hints guys. I really should have been able to figure this out by myself

I switched to 15x15 cm @ 300 dpi and it seems like I will be able to use this for print.
Right now I'm still testing with my JPGs and voilà both objects render with all materials and all coatings just as they should.

I'll probably move back to PNGs if the filesize doesnt increase massively.

About the JPGs though: they are pretty handy if you use alot of Weightmaps as I do.
Since these are simply b/w masks you save alot of memory and time since JPG encoding will save the pixel lines that have the same color instead of saving every pixel.

Of course, as Mesut said, mxcl will have to decode them but for the entire workflow before the rendering the files will be very zippy


Mesut & Mihai thanks a bunch, I guess I might even make the deadline now.
I owe both of you a very tall cold beer.

Btw, mesut I'm in Berlin very often so I'll let you know

[kami]

Since these are simply b/w masks you save alot of memory and time since JPG encoding will save the pixel lines that have the same color instead of saving every pixel.

aren't you mixing it up with gif's?

[mashium123]

I owe both of you a very tall cold beer.

Btw, mesut I'm in Berlin very often so I'll let you know

YES!!! STRIKE!!! Looking forward...