Cities in Maya / mental ray

#5

So here are some of the challenges as I see them:

Instance Sources – Should instances be single buildings, or entire blocks? How few generic buildings can we use to make a convincing city? My current thoughts are that the “downtowns” will be mostly unique buildings, but the outlying buildings will need to be generic modules.

Layout – cities have pretty distinctive layouts, which will probably be best handled by a combination between procedural and manual placement of blocks. Instances of building modules will have to follow these layouts and be placed accordingly.

LOD – Are dynamic LODs worthwhile when using instances or binary proxies?

City Dressing – All of the bits-and-pieces that make a city more than just a collection of buildings – street systems, roadworks, streetlights, traffic lights, overpasses, crosswalks… These would probably be a good source of optimization with instances and proxies, but will have to be placed according to strict rules.

#6

Assemblies vs. Proxies vs. Instances

Cities will require multiple shaders assigned to each building, and the ability to vary the shaders somewhat on each as well. From what I’ve gathered so far, only assemblies will allow multiple shaders on proxied geo, but they are by and away the slowest process.

I’m still researching, but anyone have any thoughts about this?

#7

With instances and proxies you can also have multiple shaders, but they’re on a per-face level. The object has to be combined; it keeps its shader assignments but to alter them isn’t easy. The dependency graph takes a crap anytime you try to do something like this, coupled with your GPU trying to sort the display. It’s slightly faster in bounding-box mode, but the real hangup is the single-threaded dependency graph.

That is to say, if you want to replace a shader on leaves after your instancing/placement painting, you go into Hypershade, right-click-drag on your material then pick “select objects with this material” or whatever, and then wait. For awhile. Maybe 2 minutes, maybe 200, depending on the amount of objects and faces you’re dealing with. In bounding box this is much faster, but again only part of the process speeds up by removing the GPU from the mix; the dependency graph still sucks. Totally CPU-bound, and totally single-threaded. I have isolated this difference between my Athlon X2 @2.5GHz, a Phenom X4@2.5GHz, and the new Phenom X6 @ 3.3GHz. The Phenom and Athlon had roughly the same perfomance here, and the new X6 has shown itself to be proportionally faster, but nowhere near twice as fast.

Then you assign the new texture in Hypershade the same way, and again wait a long time for it to update. Often you will think Maya had crashed entirely. One core, pounding away with no visible feedback or result until it’s finally finished. I’ve had this process take five hours before; I really hope there’s a better way.

All this said, with a city you won’t be dealing with quite the geometry polycounts you would be with trees and flora. So it might be much faster indeed. And like I said, I’d love to know I’m reassigning materials the wrong or slowest way. Any input would be appreciated.

#8

Thanks, Sho!

I may have a (slightly) faster solution for that particular problem… I’ll do a little research and get back with you.

Is there a way to change these shaders per-instance, or per-proxy?

#9

instancing highres objects with nParticles in Bounding Box mode works quite well I think. With a little bit scripting I can imagine you could place the buildings with a rotation of 0,90,180,360° and with “self collide” they don’t even overlap to each other.

But it’s difficult to obtain a realistic city, I think I would place them by hand and then converting each blocks to proxies if ever. A good looking tree has about 1-2million faces - I don’t think a building would reach that polycount. :surprised

@InfernalDarkness
About the shader assign problem. I hate it too but what I’ll do in this case (a little workaround) is to put the new shader in the “material slot” of the old shader’s shading group. So I don’t have to “select objects with material” and it’s fast. :shrug:

#10

Assemblies vs. Proxies vs. Instances Cities will require multiple shaders assigned to each building, and the ability to vary the shaders somewhat on each as well. From what I’ve gathered so far, only assemblies will allow multiple shaders on proxied geo, but they are by and away the slowest process. I’m still researching, but anyone have any thoughts about this?

If you are using Maya 2012 you can use the User Data shaders to alter the shader assignment parameters on instances, etc from one shader node and a script.

#11

My buildings typically reach 20-50 thousand faces – Also, cities tend to have a bit of foliage themselves :smiley:

#12

Interesting, I’ll have to look into that a bit more. Are there any tutorials / docs out there?

#13

Juuuust out of curiosity, is there a reason not to post any vray/renderman studio specifics in here ?
:slight_smile:

#14

for me, mainly, it’s because I’m poor.

I’m one of those artists who has to make lemonade with the bundled software (which is remarkably affordable – free, in fact for educators).

So I’d prefer to keep this thread focused on mental ray. I’d rather not have it turn into a flamewar between rendering solutions, which seems pretty inevitable whenever they’re allowed the same space.

Still… if you’ve got some links to good vray/renderman resources, feel free to share!

#15

(I’m sure you know this already)
If you’re an educator, or educatee(?), then it’s cheap to purchase for non commercial use.
Anyway, I understand it’s good to use what is bundled.

Actually, have to say your assumption is a teeny bit wrong - we had a discussion recently about many renderers and not one single childish argument broke out AT ALL !!!
:surprised

hehe - seriously…have a look if you’re bored:
http://forums.cgsociety.org/showthread.php?f=7&t=978743
:thumbsup:

Well, I like your script as mentioned in the other thread, so I’m hoping I can learn and apply something whether it’s MR/VR/RMS for the end result. I know the forests thread went into specifically MR solutions/proxies which was massively useful.

#16

@InfernalDarkness
About the shader assign problem. I hate it too but what I’ll do in this case (a little workaround) is to put the new shader in the “material slot” of the old shader’s shading group. So I don’t have to “select objects with material” and it’s fast. :shrug:

m0z, you just saved me 40 billion hours of waiting! Thanks so much, can’t believe I didn’t try that myself but you’ve saved the day, once again! Ed, we can consider the texturing-replacement issue… well, a non-issue, now. I’m happy for once that I was doing things the longest, wrongest way possible!

#17

Glad this thread’s already helped someone!! Now I just need a solution this fast when re-applying materials to only individual instances. User-Data-Shader-Research, here I come!

#18

True, and I want to start learning vray some time soon. For now, I have access to sixty mental-ray-only workstations. Pretty good incentive to stick with mr for now!!

#19

Thanks for the Script:thumbsup:

#20

What about the poor kids !
Are they stuck with mspaint whilst you render :wink:

Anyway, back on track.
:smiley:

#21

:thumbsup:
glad I could help.

@EdtheHobbit:
http://kiryha.blogspot.com/2011/04/userdata.html
:wink:

#22

mm that data shader is interesting…isnt it kind of replicating the behaviour of a 3 way switch? im sure its more flexible but does MR recognize swicth nodes? just wondering

#23

user data is more native to mental ray and more flexible for data types. With a little python script you can assign it and connect things easily through selection. (I’ve always hated the switch nodes in Maya for some reason, possibly irrational.)

I expect more of these tools will begin floating around soon, it’s not exposed so it takes some time.

#24

Thanks man! I’m going to put together a bit of a test with this soon, and probably make a couple of MEL scripts to go along with it. And switch nodes are a pain in my a$$ – probably just because of the DAG…