Saving or Rendering

[Pitcher]

I am running Version 18n 64 bit on a computer with 8GB of RAM and an i7 64 bit processor. Sometimes, it takes 10 to 14 hours to save my work. I work in wireframe and sometimes stop and render along the way so that I can see what the patches look like. I am wondering if there is a way to shorten the saving time, or is there a way to know when rendering time for a frame is going to exceed 7 minutes or so, before I press the render button. What happens when I render sometimes is that the computer buffers (twirls) and twirls indefinitely. I try to abort, and the rendering program seems to abort but twirling continues, and I cannot get back to where I can start the 10 to 14 hour save. Usually when this happens, I have to kill the program and restart and lose all my work. Is there a happy solution to all of this?

[Fuchur]

short answer... no. long answer: hit esc or the renderbutton again if you are using the progressiv renderer. this should work most of the time but not always...

 

if you are really rendering stuff in final rendering this should be cancelable.

 

the tjing i do: before rendering i save with ctrl+s. like that even if something goes wrong you still have your work.

[Rodney]

it takes 10 to 14 hours to save my work.

 

Something is definitely wrong there.

At the most it should only take a minute or two to save a file.

Normally it will only take a few seconds.

 

Yes, Fuchur has got the right advice! HItting the Escape (Esc) key should bring you out of a render and back to life.

Rendering should never lead to losing work and *if* you get in the habit of always saving *before* rendering you won't ever need to.

At times I've thought about putting in a request to have A:M save prior to rendering but there are times when folks may not want to save over a current file and just want to see the rendering results. Still, it's a bad habit not to save before rendering. The ideal process (in my estimation) is to save with an incremental number or letter in the file name. As this is similar to rendering sequential images that would be part of the feature request too.

A:M does have a Backup feature but it isn't triggered by new (final) renderings. That's be nice.

Other than saving a lot of heartache losing files the other thing that is good about saving before rendering is that saving to file frees up more memory for the renderer to use as A:M doesn't have to worry about unsaved changes or memory caches. Examples of incremental filenames could include:

 

MyfileName A 001.prj

MyfileName B 001.prj

MyfileName.B 002.prj

MyfileName B 002a.prj

 

How you name the file isn't as important as the fact that you've saved the file under a new name. In this way you can get back to a previous version of your file if and when you need to.

An exception to this would be if you are saving your files to some place that automatically maintains a version. This is true of some cloud services.

 

I haven't done it lately but in the past I use to number my files incrementally but letter my files in reverse alphabetically order. Example:

 

ThisIsaVeryCoolToonRendering Z 000.png

ThisisaVeryCoolToonRendering Y 000.png

ThisisaVeryCoolToonRendering X 000.png

The idea behind this was to give me a sense of moving toward finality/deadline because as my file approaches the letter A (after starting from Z) I know it had better be getting close to being done. At a glance then I could see that a filename appended with a letter 'M' was very likely good enough to call 'done'. Especially if there were a bunch of letters between N and Z and none between A and L. Of course, instead of the letter a few words about what changed in the setup/project would work even better. Example:

 

Particle Sprite Fireworks Blue 50 particles per second v1.prj

 

Hope that makes sense!

 

At any rate. The advice is save often and save incrementally.

Followed by the secondary advice, 'always save right before you render'.

 

[Pitcher]

Thanks for the advice, Fuchur and Rodney! I like to save often, but when I get in the final stages of building a model and it is taking half a day to save, I like to get a little work done between saves. I'll know for sure that I want to save before rendering. I had hoped to get a picture of what it looked like before turning it loose, but I'll know better next time.

[Rodney]

I know what you mean. I think we all like to see our efforts rendered.

I trying to cure myself of that!

 

There are some ways we can get a good look at what the render may spit out for us.

Render Lock Mode (Shift Q) is the main one I use (although I'd like to try to cure myself of using it). It's the one that we need to hit the Escape key on to tell A:M we don't want to see that preview.

If there is a specific part of the screen/render we need to see we can hit the Q key by itself and then drag our mouse (while pressing down the left mouse button) and that will preview render that selected area of the screen. This won't render to file, it's just for us to get a quick look at what the final render will look like. There are some other options as well but I don't use them often.

 

I try my best to stick with the realtime view and just get a sense of what the final render will look like based on that. The more complicated the scene (lights, particles, etc.) the more the final render will diverge from that previs.

 

One thing you can to also is just render one frame of a sequence before turning the renderer loose on the full sequence.

\

it is taking half a day to save

 

 

Like I said, something is very wrong there.

It'd be good to figure out what that is.

I must assume here that by 'save' you don't mean 'render' as those are two very different things.

[Pitcher]

Yes. I appreciate the additional information on how to partial render to get a look. That will probably help a lot.

 

I agree also that saving should be a very short process, but this happens every time I get one of these huge models pretty far along. In this case, it started "the long save" about 1/4 of the way through. One time, a tiny window popped up and said I had something like 140,000 patches in my model. It was as if the program was protesting, because after that, the program became more and more finicky. I got rid of that window and continued. Now, I estimate that it's at about 300,000 patches. The model is a six story office building with 240 windows, 14 doors, and quite a few other details. I'm not sure what the saving process in this model is actually doing. I usually save about every 10 minutes until the "long save" process starts. Do you have any ideas why saving is taking so long?

[Fuchur]

do you mean save or rendering to an image sequence... if you really mean saving the projectfile and you need that much time for that something seems to be wrong. or how large is the project file you are working with?

 

in general that should not take more than a few seconds to save a project file.

 

see you

*fuchur*

 

ps: just read the thing with 300k of patches... that would be one of the biggest models i've ever heard of build in A:M. in general you would split that into many smaller models and combine that in a chor afterwards. arent you getting very long finding patches times with that?

[Pitcher]

Really, I am talking about saving the model when I say it takes 10 to 14 hours. I am not talking about saving the project file. When I say I am rendering, I'm talking about a final render of four frames using a model file. The first frame sometimes goes crazy and twirls indefinitely. If the first one goes OK, the rest follow within seconds. I just make four frames for no particular reason. They are all the same. This is just a model file.

 

I'm not sure how to get back to the little window that gives statistics on my model. The only time I saw it come up, it came spontaneously on its own. I just read the statistics at the time, closed it out, and continued working. That was about 8 or 9 days ago. This model has been in development for about 3 or 4 weeks. I do things in pieces, too, sometimes, but I did not see how I could reasonably divide this up. Actually, this building will be part of a cityscape. It will be one building among many in a chor. When I described the building before, I forgot to describe one of those additional details I alluded to earlier. I have about 800 or more decorative roof braces that are just under the eves of the roof on two levels of the building. That probably elevates the patch count considerably. After I added those, the "long save" started. The 240 windows just made matters worse. The basic building is no big deal at all. I'm in the middle of a long save right now with the twirling going. I cannot use the program when it twirls. When it finishes, I will look for the window with the statistics. Do you have any idea where to look?

 

Also, one more thing I should mention. When the program twirls, I normally don't use the computer for anything else. I work on an older one. Sometimes, I do a few things on the main computer, but that's when I'm desperate. Sometimes, it messes up the save, and sometimes it doesn't.

[Rodney]

I think we need to introduce you to the art of instancing.

It's far easier (from the programs vantage point) to save a link to a resource than the resource itself copies many times.

 

A question that might be asked is, out of those 800 or more decorative roof braces how many are exactly like each other?

If the answer is 'They are all exactly like each other just put into different places' then you can drop that patch count tremendously just by referring each one back to the original. The the file only needs to save the original plus the 800 textual links (not sets of patches).

 

I'm in the middle of a test (creating a cityscape of hundreds of buildings with hundreds of windows) to see how much it slows down my computer.

At present A:M has ground to a halt while it's attempting to save the model.

In a little while I'll try the same thing with referenced instances of original models.

 

I guess what it boils down to is determining how many unique shapes you have in your setup and then optimizing your project from there.

You mentioned 240 windows. I assume that is 240 of the same window duplicated over and over again.

 

 

...and of course, once you have the model rendering perfectly that'd be a good time to capture that render for use as a decal so you can place the resulting image back on a model with minimal patch density. In that way a 300,000 patch model can be whittled down to (easily?) less than 100... give or take areas where you may need close up detail.

[Fuchur]

You can access that model-info by going to the modeling-window, right-click in a free area and click on "info".

See you

*Fuchur*

[NancyGormezano]

In this case, it started "the long save" about 1/4 of the way through. One time, a tiny window popped up and said I had something like 140,000 patches in my model. It was as if the program was protesting, because after that, the program became more and more finicky. I got rid of that window and continued. Now, I estimate that it's at about 300,000

 

Yikes. 140,000-300,000 patches! A:M starts bogging down on my machine when a model becomes more than 15,000 patches.

 

Large patch count models are handled best by having many many different models, and assembling them all together in actions. That's how the enormously overly detailed sets (detail which was never to be seen usually) were done on Tin woodman of Oz and Scarecrow of Oz.

 

What you can do now:

1) Yes get rid of those 240 windows - either by making them a decal (my preferred way) or

 

2) if you insist on having modeled windows, other modeled detail, then SPLIT your model up by copy, pasting just the windows (and other stuff) into multiple new models ie, into however many new models it will take to get each model into a reasonable size patch count - say 10,000ish.

 

3) Create new action (or new chor) - starting with bare bones building shape, ie cube, or whatever you have left on bare bones building after deleting all the stuff you moved to new models. Drag the new mini models into action (or chor). In an action they will become action objects

 

In my opinion it is hard to work with action objects in actions to build something...but thats how the obsessed worked with them in TWO and SO.

 

It is easier to import all the models into a new chor, delete all lights, cameras etc from chor, save the chor; which now, is really saving just the "pointers to the models - ie instancing.

 

You can then import that Building set chor into any other chors, and it will bring everything in.

 

Hope that was clear?

[robcat2075]

Instancing, modeling parts separately, then assembling them in the chor, as noted above, are important tips.

 

I'd be curious to see the RAM usage of your computer while you have all this loaded. Maybe even 8 GB is getting overrun and A:M has to resort to "disk swapping" which is a term you don't hear much any more.

[NancyGormezano]

Heres what an insane Assembly action with gawd knows how many action objects looks like that was done for KuKlips workshop (this is for both interior and exterior) - pure craziness.

 

Also note with actions, and chors that have so many models - it might take 1-2 minutes to load...

[Rodney]

Everything is generic (modified cubes) in this test but I wanted to get the patch count up higher for testing purposes.

If I calculate correctly this Chor has the equivalent of 77,000** plus patches which are instanced from 1 original file (consisting of 6 buildings apiece that contains approx 11,000 patches).

The Project file (with everything embedded in it) saves immediately.

While I'd have to check, I believe the Project file also contains the individual story of one building that is duplicated three times in height (to get 4 sections/levels per building).

If doing this again I'd probably make the windows of a type that could appear more detailed as well as give the tops of the buildings some type of detail.

 

All of the buildings where turned 45 degrees via an action before being exported out into groups of six buildings.

 

In the image you can see top center a building that is larger than the others.

This was a quick test to resize an instance (not the original) via a Chor Action.

To get differentiation in similar objects that have varying details... that's where Poses (pose sliders), Actions and such come in... but none of which are in this test.

 

I know your setup is more detailed but am just going through the paces of testing to see what might be causing the specific issues you are dealing with.

If you have tons of patches that will definitely take more time for A:M to process.

If you have copy/pasted tons of patches that aren't optimized that will take additional time to process.

 

In the image you can see top center a building that is larger than the others.

This was a quick test to resize an instance (not the original) via a Chor Action.

 

 

It can help to think of Modeling in similar way to Animation. We don't blast every bit of information into one frame but put what is needed where it is needed throughout. One of the benefits of computer animation is reusage where we don't have to recreate everything... every time... from scratch. We can just point to the resource and say, "(As a starting place) reference that."

 

 

Edit: Nice example Nancy! I wish I'd thought of that.

*Generic project is attached

**According to A:M''s Info setting (RIght Click and select Info) the Chor contains just over 86,000 patches (remember though that only 11K of those are original patches).

81K plus.prj

[Pitcher]

This is fabulous! This is just the information I needed. I will review this and use these tips. As I mentioned, this has been a continuous problem for me for a long time. I just got back from a birthday lunch where I ate far too much. I'm going to go take a nap and get back up and read your suggestions again and make them part of my standard practice. I'm not sure if you mentioned it, but is there a way to incorporate something like a 30 degree turn on the y-axis in the procedure for referencing the same model as it is used over an over again? I was just thinking about the forest I did in another model a year or two ago.

[Rodney]

is there a way to incorporate something like a 30 degree turn on the y-axis in the procedure for referencing the same model

 

Yes, there are multiple ways to approach this the simplest way being just to rotate the instance 30 degrees and be done.

For more automation (of turning of many trees) I'm sure a random expression could make sure every tree in a scene is turned slightly different that the others.

 

A breakthrough in Modeling for me occurred when I saw other people Modeling in a Choreography. I was like.... whoaaaa... we can do that?!?!

To keep file sizes low we would then just save the entire Project (or Chor... some people don't save Project files... only Choreographies.... but this is a tale for another time). If the desire were to be to have everything as one mesh (and not modular parts of a whole) then all we have to do is export to Model from the Chor.

[robcat2075]

It is indeed possible to use a random expression to vary something multiple instances of a model. There is a thread about it and I have a sample PRJ in it.

 

There is also a plugin in called SimpleScatter that will distribute multiple copies of a model on a selected plane, although I just tried it and it is behaving oddly.

 

Also behaving oddly is the Multiple Models on a Path plugin , but it does exist.

[Pitcher]

There are several parts of the answers above that intrigue me. First, you mentioned putting one instance of a model in the file and replicating it by reference. I would like to know exactly how to do that. (The windows were all the same generally except for a color difference on a few. The 800 or so roof braces were all the same. The trees in the forest were all the same.) When I talked about rotating each 30 degrees, I really meant each tree. Your idea of an equation that would rotate them randomly would be the goal. I would need to know where to write such an equation. I am interested in know how to replicate by reference and then position the referenced models. For example, I have the 800 roof braces spaced around the perimeter of the building. How could I position the referenced braces?

 

As far as using decals for the windows, I thought of that earlier, but I would lose a little texture. I already plan to use quite a few decals on the bottom story on shop windows. I did not want the entire building to look flat. I still might end up making the windows decals, however, and I am prepared to cut back on my expectations if necessary.

 

Another idea I liked is that we can model in a chor file. I never have difficulty with size in a chor file. The only place I've had difficulty with size is in a model file. Most of the time I could avoid that by breaking up the model, and I have done that when convenient. I would like to know how to build and save models in a chor file.

 

I am still interested in knowing what the program really does when it saves in a model file. Is the model file really a large data base with each control point and spline referenced in three dimensional space with patches calculated and colors entered? Is the computer running through the database comparing what we have shown on the screen with what is already there? Do certain types of changes make the computer work harder than other types of changes? I'm guessing from what you said earlier that the rendering program references the saved database and then identifies changes that have been made from the saved data. That's why saving before rendering is so important. The rendering program has more difficulty, the more changes have been made since the data was last saved.

 

I really appreciate the effort everyone has gone to in answering my questions. Rodney, your city of skyscrapers is terrific. It's not really what I was going for, but I like it. My problem this time is with the one building that uses so many patches. My cityscape will be various kinds of buildings as seen from ground level. For example, there will be a block on one story shops, a Victorian home, a park with a fountain, a six story office, apartment, or hotel building with shops on the bottom floor, an office skyscraper, a parking structure, a museum, a library. Some of the buildings will probaby be modified and replicated in different heights, numbers of stories, and/or colors. There will be pedestrians, street lights, traffic signs, and street traffic.There may be little efforts to add greenery to the city setting. I am looking for the whole effect to be diverse complexity. This is not a look over there and see the huge city kind of cityscape. I want it to look like a place where people live and work and is also an area in transition from what once was large houses to now museum district with large buildings on the edge. The Victorian house will someday soon be torn down to make way for some larger more modern building. Some of the more modern buildings will be 40 or 50 years old and some will be much newer, taller, and more modern. I only tell you all of this to let you know the exact kind of problem I have. I have several blocks created in a model with streets, curbs, sidewalks, etc. and now I am designing buildings to set into the empty spaces.

Thanks, Robcat. I will be looking at the information you referenced.

[Pitcher]

It finally stopped saving and I right clicked on Info. The information was as follows:

 

Total Patches = 282322

5 Point Patches = 3104

Total Hairs = 0

Total Bones = 0

Total Nulls = 0

[robcat2075]

It finally stopped saving and I right clicked on Info. The information was as follows:

 

Total Patches = 282322

 

I'm surprised it works at all.

 

 

 

 

 

Here is an example of shape ("Right Angle") modeled once , then distributed along a circular path ("Path 1") in the chor with the Multiple Models on Path plugin.

 

Select a path inthe chor and >Plugins>Wizards>Multiple Models on Path to bring up the settings.

 

[robcat2075]

Is the model file really a large data base with each control point and spline referenced in three dimensional space with patches calculated and colors entered?

 

 

Yes, it's a long series of nested lists. A list of splines defined by a lists of CPs. A list of patches with the list of CPs that make up each one. And many more

 

It's all saved in readable ASCII text. You can load an A:M file in a text editor to see the XML tags that start and end each list.

 

My "It can't be done: Painting with Light" has an introduction to looking at files in a text editor.

 

 

A:M loads all data in RAM while you are working and doesn't revisit the hard drive until you save again.

 

 

 

Is the computer running through the database comparing what we have shown on the screen with what is already there? Do certain types of changes make the computer work harder than other types of changes? I'm guessing from what you said earlier that the rendering program references the saved database and then identifies changes that have been made from the saved data. That's why saving before rendering is so important. The rendering program has more difficulty, the more changes have been made since the data was last saved.

 

 

As far as I know... A:M writes the file fresh from RAM every time you save and only uses what it has in RAM while it is rendering, it doesn't reference the last version of the model on disk while it is rendering and doesn't reference the last version of the file while writing a new one.

 

Saving before rendering is for safety, really, in case you crash during the render.

[Pitcher]

Thanks, your information helps. Sometimes, if I can slightly understand what the program is really doing, it helps me avoid some problems.

 

I have been thinking of ways I can use the decal and still get down the number of patches without losing the 3-D quality.

 

I never have really understood, however, how to import only one copy of the model and then replicate the rest with written statements. Where do I write and what do I write?

 

I'm nearly through with this model, but all of this will help me to avoid the problem in the future.

[robcat2075]

Thanks, your information helps. Sometimes, if I can slightly understand what the program is really doing, it helps me avoid some problems.

 

I have been thinking of ways I can use the decal and still get down the number of patches without losing the 3-D quality.

 

When you can show it to us perhaps we can assess the possibilities better.

 

 

I never have really understood, however, how to import only one copy of the model and then replicate the rest with written statements. Where do I write and what do I write?

 

 

There isn't a way to do that inside A:M. When people are talking about instancing they talking about dragging the one model into the chor many time.

 

It would be possible with text editing and a spreadsheet to automate that process.

 

I will note again, my series on "It Can't Be Done: Painting With Light" explains the process of text editing quite a bit.

[Pitcher]

I will go through your tutorials as soon as possible. I also will start either breaking up the model or removing patches where possible. I will let you know how that goes. Thanks for your help.

[Pitcher]

I have been removing every extra patch I can find. I have been breaking up the model into pieces that could be put together easily. I have been eliminating redundant pieces. As I have spent time doing this, I have adjusted to the new world view.

 

I resisted at first, because I thought of modular construction as discreet pieces put together like building blocks, and at some point, I experienced some slippage in the location of parts I added in a chor file. I did not want to put parts in a chor file that had to fit together without much variation. I now see the many advantages of dividing even a single unified model into components. For example, I have the six story office/apartment/hotel building with decorative flourishes and rows of windows. I have, from the beginning, planned to use it in several heights and colors. It will be much easier to make the changes if I break the building up into "basic structure," "window row 1" (with windows trimmed in one color), "window row 2" (with windows trimmed in a different color, "roof braces" (with a row of decorative braces placed around the roof), and "doors" (with doors located in relation to the basic structure). I can modify the parts as needed more easily and add additional instances of the parts more easily as I expand the building in the chor file. I also think I can find a way to keep the parts in place in relation to each other.

 

One other concern I have that makes me a little resistant to modification is that I never want the program to dictate the final result. I know in my head what I want my scene to look like in the end. Other people might not think the idea is very good, but I do. I do not want to change my idea of the outcome, because the program has some limitation. One of the things that worried me was the observation that there was detail in the Tin Woodman that was unnecessary and unseen by the audience. To me, the great strength of the Tin Woodman was the detail. I loved seeing what the program would do. I don't ever want to settle for less than my original idea because I think the audience would not appreciate the difference. That's one reason why I end up with a model that has almost 300,000 patches before I mention the problems I am having. I am willing to push this program to hell and back to get what I want as a final look. I am retired and have time, and I am willing to spend a little extra time. Finally, however, I thought that this just seems too weird, and there might be a fix.

 

Thank you, Everyone, for your great advice and efforts to provide examples and so forth. You have convinced me.

[robcat2075]

I would say that every workflow has limitations or impediments, on one end or the other.

 

 

and at some point, I experienced some slippage in the location of parts I added in a chor file.

 

 

Slippage? You may have to explain that more.

[Pitcher]

I thought slippage might get some attention. When I was having characters square dance, they would be lined up properly holding hooves, and then I would come back to them, and there was visible space between them. Their hooves did not meet the way they did before. It also seemed at times as if the buidings would shift slightly. That's what I meant. Maybe it was my imagination, but it happened frequently. I notice that when others plan dance scenes, the dancers usually dance as individuals rather than holding hands. I thought maybe other people had slippage also and had planned their scenes accordingly.

 

I also read about procedures for having a character pickup a glass and take a drink and then put the glass down. It seems that special procedures are necessary to keep the glass in the character's hand. I wondered about keeping the building together. Is something special required?

 

I seem to remember in the dancing daisy lesson, it is necessary to link the leaves to the stem so that they don't separate during movement.

 

There might also have been a statement about some slight movement just due to opening and closing the program over and over again, as if the picture suffers some bit of degeneration. That's another reason why I was afraid to put buildings in pieces unless they were designed more or less like building blocks that would be easy to shove together.

[Rodney]

Objects don't tend to move for no reason so we'd just have to figure out what that reason is and address it.

I'd say one of the most likely reasons is that something is accidentally animated.

 

There are several ways to get a group of objects to move as one object. The first would be to make them the same object (i.e. combine them).

 

Another approach would be to establish a Relationship that treats them as the same object (or as Parent/Child).

This is usually the approach of using Bones. Where the mesh on one or more objects is assigned to a single bone those objects will move together as if it were one.

 

Where two or more bones are involved that aren't in a Parent/Child relationship objects are constrained (manually linked) together in such a way as to dictate their location and orientation. It should be no surprise here that the method used here would be to use Constraints of which there are many types; Translate, Aim At, Orient Like, Path Group, etc. Quite often a Bone that doesn't have any mesh attached to it will be used as the target of a constraint. A special bone called a Null is often used for this purpose. An example of this would be having two eyes (each having their own single bone) following a Null via an 'Aim At' constraint. In this way wherever the Null is located the eyes will follow.

 

The most likely reason objects move (when no movement is desired) is that we have created that movement on the timeline. This can usually be avoided by making sure we are on frame 0 of the animation (as opposed to some other number where a keyframe will be generated resulting in the unintended movement. Another way we can prevent keyframed movement from occurring is to turn off the option to create keyframes (via the Animate button - the A button on the top menu). Just be sure to turn it back on or the problem will reverse and the question then become, "Why isn't anything I animate moving?"

[Pitcher]

Thanks. That will help me master the problem.

[robcat2075]

I've never seen an object drift without having been keyframed to do so, perhaps inadvertently.

 

If you can make a sample PRJ that shows it that would be illuminating.

[Fuchur]

very likely just the interpolation type of keyframes which is getting in the way here...

[Pitcher]

I wasn't talking about a lot of movement. Just a tiny bit can make the parts of a building show a little space or hands that should be joined show a little space. You can also see a little movement when you are straightening lines on a building, and the points that should be lined up (meaning that you lined them up manually many times), but then after several more sessions where the program has opened and closed, the points are no longer lined up exactly. Anyway, I am prepared to live with all of that. It doesn't seem to be a major difficulty compared to working with huge files.

 

I have not finished with my town scene yet. I will probably keep tweaking the buildings I have, and I will add many more. I have now broken the huge file building down into many parts and reassembled the parts in a chor file. I am posting several pictures of the building below after I have assembled it in a chor file. Robcat had mentioned wanting to see it before making any further suggestions. Maybe this will help clarify what I have been describing. The little strip center building behind the multistory building was never part of the file I have been discussing, nor was the house or its grounds.

 

[robcat2075]

If the large building will be seen at distances and sizes like these shots I think the windows might be done with bump/displacement maps and color maps.

[Pitcher]

I need to learn about that.

[robcat2075]

Here is a quick example of color map and displacement map at work...

 

[Rodney]

Yes, that'd be a great way to go (for long shots) and it'd reduce your patch count from it's current number to somewhere around... 20 patches.

That number of patches will save really fast.

 

Of course you'd want to keep (at least sections) of the more detailed building or some facades for close up shots such as for use with someone standing in or looking out of a window, walking through the front doors, etc.

 

Not to complicate the approach that Robert is suggesting but as desired using a transparency map the (black) of the windows could be made partially (or completely) transparent as well.

I'm not entirely sure how well that wil always work with displacement maps also in the setup but as long as the displacements aren't too crazy it should work well.

 

Added: Another thing the approach does is speed up the entire process for a production. If we don't spend a lot of time initially on models that require less detail we'll have more time for additional detail later where we deem it necessary.

[Pitcher]

Thanks very much for the help. The example is especially nice. Sometimes I get so busy doing some of this stuff the only way I know how that I don't take time to learn new things. I'm at a stopping place now and will be looking more closely at the examples and the tutorials.

[Pitcher]

I was unfamiliar with how to make a displacement decal or bump map, but I found an explanation for using a bump map or displacement map on pp. 432-448 of Animation:Master, A Complete Guide by David Rogers, 2007. If anyone else is interested who isn't familiar with these, Rogers book might help.