View Full Version : Using Pflow to create city - real world mapping question
09-16-2007, 10:52 AM
(I've also posted this on Orbaz.com)
I've been trying to use Pflow to create an aerial view of a city, the theory being that it might be less memory hungry than, say Greeble.
I have been trying to use real world mapping co-ordinates on the textures for buildings so that windows stay a consistent size, regardless of the size of the building object.
I'm a little hazy on how real world mapping works, if using that means that unique UVs are store per object (meaning that they are no longer instanced).
Anyway, I don't seem to be able to get Pflow to recognise the real world mapping, so the windows scale in relation to the size of the particles.
I've tried using the mapping object from Box #1 and picking another box with real world mapping applied, but that didn't work. The standard mapping operator doesn't mention real world mapping either.
Of course I could snapshot the resulting particle system, but then that I lose the advantage of instancing.
Any suggestions are welcome.
On a sidenote - has anyone come across any good procedural systems for generating cities? I've seen a couple of Siggraph papers, but nothing commercial seems to have appeared.
I was impressed by the description of Weta's tools which built New York for Kong, using building blocks and rules - I would have thought something that could do half of that would be a big seller.
09-16-2007, 02:45 PM
The real world mapping option just controls the size of the tiling in max units so that if you have objects of different sizes, all you need to do is make sure the alignment of your mapping gizmos is correct and real world mapping is turned on. The real world mapping will make sure that the size of the map is the exact same across the objects. If you had an image of a single brick for example and you used real world mapping with the size set to 10 x 10, it'll mean that one of your textured bricks will be ten units by ten units in your max scene - just makes it handy if you're doing a big city scene and don't want to worry about having uvw gizmos the same size but still want consistent bricks.
As regards pflow, I think it might be a bit of a problem with the mapping gizmo - since real world mapping is part material setting and part mapping gizmo setting I'm not sure if it'll get it. How about using pflow for the distribution, scale, rotation and randomness only and then transferring the transforms to regular max objects? Should be a lot easier on memory too with instancing.
As John suggested, I would use PFlow (if at all) as the "rule" for distribution, not as the city itself. The idea behind particle systems (at least in Max) is to create a single object which controls the behavior of many objects based on the same set of rules. Since houses are not moving, most of the time PFlow would not have anything to do with your houses once they are distributed. PFlow creates one gigantic mesh out of all meshes of all particles (or multiple meshes if requested), but it is very similar to creating thousands of copies and then ATTACHING them to a single EMesh!
A much better approach would be to create a number of building blocks that can be fit together, then create INSTANCES of these blocks and place them at the calculated positions - this way, the memory hit would be orders of magnitude lower as compared to PFlow, and you would still be able to make any clone a unique copy and adjust settings locally after the fact. Plus, the real world mapping would be preserved. Obviously, this would require some basic scripting to get the TM from the particles and clone houses...
Of course, as you would expect, I would rather script the behaviors and not even use PFlow for the distribution. In fact, I did just that for a demo script Autodesk was using at Siggraph to showcase some new features of Max.
09-16-2007, 04:03 PM
the original thinking behind using Pflow would be that it be more dynamic and repeats would be less obvious to spot - and I could maybe control distribution based on an underlying map - that was the thinking anyway. I also thought particles were instanced rather than a huge mesh, which was another reason for using it.
There was also the slowdown that Max has (at least until 10 ships) with processing lots of objects, although making larger instanced chunks alleviates that at the expense of being able to easily change the look in one click.
I'd love to see a commercial application/script along the lines of Cityboy described here
09-16-2007, 04:03 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.