lowering polygon count

[maetoch 0]

i want to import a figure from poser into BAT. when i do the figure has a poly count of 30,000+. is there a way to reduce the polygons of the figure?

[Constantina 5]

So far I can tell you I cannot think of a way to do that. Probrably having a go with merging polygons?

[ILL Tonkso 1,236]

Convert everything to an editable poly, it can more than half your poly count, anyway 30 thousand is nothing lol, thats really good. The average skyscraper will probably have around 50-60 thoudand.

[Jasoncw 11,840]

Does it really!? Everything of mine is in extruded splines or meshes.

Does having complex .psd files as textures make the render time longer? Maybe because gmax needs to render the psd? I've been planning on testing it but I haven't gotten around to it yet.

The Detroit Free Press Building that I'm working on is 174,000 polygons, it got brought down to 59,000! yikes!

[tungston 19]

I am not sure how poly count relates to rendering time.  I have a building, and for the sake of ease, I will round off the deminsions.  It is 64x64x300 meters, the poly count is 100,000.  This takes close to 3 hours to render.

Take the same building and reduce the size to 25% of the original, clone itand set it side by side, and the poly count goes to 200,000.  It takes only about 30 minutes to render.

[toxicpiano 125]

Date: 12/23/2005 4:49:35 PM Author: tungston

I am not sure how poly count relates to rendering time.  I have a building, and for the sake of ease, I will round off the deminsions.  It is 64x64x300 meters, the poly count is 100,000.  This takes close to 3 hours to render.

Take the same building and reduce the size to 25% of the original, clone itand set it side by side, and the poly count goes to 200,000.  It takes only about 30 minutes to render.

quote>

yes exactly, rendering size is affected by the size of the model. Although a low poly count certainly stops lag...

[maetoch 0]

What I am wanting to do is place several figures around the base of the building, as if they were statues. Right now my buildings avereage between 20 and 30 thousand polys and they are only 1x1 tile buildings.

[vester_DK 477]

I remember reading a port about a submarine (by NDEX maybe), where the cut down polygon count. It has been released on STEX.

They used some kind of script or routine.

[ILL Tonkso 1,236]

Poly count DOES effect render time, (i have experimented) for example, my 4 eastland grand is smaller than my 25 canada square, 25 canada square has around 50k polys, 4EG has around 120k polys, 25 CS rendered in 8, 4EG rendered in 22

[toxicpiano 125]

thanks a lot! now i feel like a moron!

[paulvmontfort 616]

I still think polys don't affect render time. I think it's the LOD shape, volume, Additional lights really matter, I could be wrong though

 

BTW, I don't know if anyone knows my Pacific place project around here, but I managed to keep it around 150,000 polys and there are 4 40+ floor towers

[ILL Tonkso 1,236]

Date: 12/23/2005 5:39:22 PM Author: toxicpiano thanks a lot! now i feel like a moron!

quote>Theres no reason to be like that, but yes, poly count does effect render time. Also a high poly count model is more taxing on your system while actually BATting it.

[toxicpiano 125]

Date: 12/23/2005 5:56:11 PM Author: ILL Tonkso

Date: 12/23/2005 5:39:22 PM Author: toxicpiano thanks a lot! now i feel like a moron!

quote>Theres no reason to be like that, but yes, poly count does effect render time. Also a high poly count model is more taxing on your system while actually BATting it.

quote>

yes i was aware that it taxes your system, and if i chose to feel like that i will. Lets all be friends! *gives tonks a hug*

[Jasoncw 11,840]

I believe that for each light or nightlight you add it multiplies the rendering time, since the model gets re-rendered for each light.

I think the complexity of the LOD affects it too, but the polygon count is the main thing.

[ILL Tonkso 1,236]

Size is also (and obviously an issue) My Charing Cross has a low poly count but its sheer size worked up a 15 hour render.

[Jasoncw 11,840]

To answer my own question about the .psds...

I made a 5 meter cube with a 58.7M .psd with 40 layers and rendered it, and then rendered it again with the same image as a .jpg. The difference was an astonishing .055 seconds! I think this is groundbreaking.

Are there any other tips?

[kd5rax 82]

Also, its not really the size of the poly- count, its the size of the polys being counted, Very large polys take much longer to render than many small ones.  The polycount is mostly important for modelling purposes, If you get too many, it'll fill up your ram and make modelling laggy

I managed to keep the tower+mall sections of the taipei 101 tower at 187,000 polys and its 101 floors tall and had complicated geometry. (Dont ask how, I still am really not sure how I kept it so low)

Ps: try using modifiers, mesh editing, optimize to decrease the count of an existing mesh. And rember, poly count is only an issue during the creation process, and not so much a factor in rendering

[tungston 19]

Date: 12/23/2005 6:00:58 PM Author: Jasoncw I believe that for each light or nightlight you add it multiplies the rendering time, since the model gets re-rendered for each light. I think the complexity of the LOD affects it too, but the polygon count is the main thing.

quote>

I don't know if you think I am lying about the render time in my previous post or what.  The two scences have simple box LOD's, and no extra lighting.  Yet with double the poly's, it renders in less than one sixth the time.  So, where is the theory that poly count is the determining factor?  I am not trying to start an argument, I just want to know.

[Jasoncw 11,840]

^I was mostly thinking in terms of the render time in exisiting buildings, so I wasn't really thinking about the size of the building. One time I did render a big cube (the grid scale was at 256 and what I made was about 3 or 4 squares) on accident, and it overwhelmed gmax, so I don't doubt you.


Will deleting the faces of the unseen sides of things reduce the render time? If so, does it reduce it enough for it to be worth doing?

[maetoch 0]

so i guess its safe to assume that adding the figures last will be ok.

edit: how do you select the hidden polys only?

[Trigger_tre 1]

Ok I thought I might just throw my 2-cents in.

I am still working on my first BAT(so that will tell you how I know)

I rendered a 1x1 6,706 poly count tunnel in 96 secs on high quality.

I then added 4 directional spotlights....

The poly count was still 6,706 but the render time took 126 secs with the added lights on high quality. (30 secs longer with lights)

I then added 5 large spheres and 1 large box...

The poly count was 10558 with the added images and the directional lights and the render time was 228 secs on high quality(98 secs longer with the added shapes).

So just my thought is that render time has to do with poly counts, lights, size, etc. (multiple factors for render times). Maybe that will help answer a few questions>?

-trigger

I also testing the effect of web-surfing while rendering the latter 10558 poly counter image. By surfing the web during the render it added 7 secs to the total time so 235 secs.

I guess I should start shutting down the Firewall, Antivir, and the 5 other safeguard programs I have running in the background. Im curious how much time it would shave off>?

[tungston 19]

Date: 12/24/2005 4:01:10 AM Author: Trigger_tre Ok I thought I might just throw my 2-cents in.

quote>

What did you do with the LOD's while doing this.  If you just change the number of sides on a cylinder LOD, will add time to the render.  How did you fit the LOD after the spheres, and box?

[Superstar 69]

I used to create towers with up to 600,000 polys back in the day, but I know these days the trick is to use spline and splines only, now most my towers are around 30-50k which is a big difference

[shpangler 19]

Hi,

I'm trying to export a large BAT with just over 40,000 polys. I left overnight to render, but it failed and said it needed to increase my computers memory or something along those lines. It's really big, but I'm thinking it should still be able to render on my 512RAM computer.  Is there anything I can do to lower the render time???  Any suggestions would be very useful.

[3ddz 17]

Originally posted by: ILL Tonkso Convert everything to an editable poly, it can more than half your poly count, anyway 30 thousand is nothing lol, thats really good. The average skyscraper will probably have around 50-60 thoudand.quote>

 

It seems like you have only half the polygons when  you convert it, but it doesnt get you any further because the object has the same amount of triangles then before. What happens when

you convert to editable poly is that you get not only triangles but quads and so on (faces with more than 3 verts) but it doesnt affect the amount of triangles the object has.

And it gets even worse, editable polys are handled much slower than an editable mesh so you should only convert to editable poly if its needed.

[onlyplace4 603]

OK, my 5 cents worth, and this comes from 5 plus years of experience with 3DS Max. The fundamentals concerning render time are ALL the factors within the model. A high poly model will always take longer to render than a low poly model as the render engine has to calculate hidden faces, opacity, bump mapping, etc., for each and every polygon in the model. Lights then add to the equation, as each poly than has to be considered as to how it will be affected by the light(s), and also how it itself will affect the light (ie. shadows and the like).

There are no hard and fast rules here, but you should always attempt to use editable meshes for your models. These are handled more efficiently than anything else by the render engines, and that includes the standard primitives such as a box. My rule of thumb here is, when I have finished a model, I select everything and then convert to editable mesh.

Another point that is worth remembering is that an uncollapsed mesh will take longer to render than a collapsed one. However, you should only ever collapse your mesh stack when you are 100% certain that you will not want to edit one of the elements within the stack as, once you have collapsed it, that ability is lost. Also, the application of a UVW map will slow down the render, so again, once you are 100% certain that you have everything just how you want it, make sure you also collapse your UVW mapping. Oh, and always try to aim for as small a texture as you can get away with, as large textures also slow things down.

Whilst low polygon modelling is always something to aim for, within the realms of SC4 it is only really necessary for faster rendering. High polygon models will not cause any lag in the game, they just take longer to get in game in the first place! Some people say that high polygon models produce larger export files, but I have yet to find this. I made two version of my Slaytfork Mill model - one high polygon and one low polygon, and on export, surprise, surprise, they both had the same file size!

Basically I would say that, if your system can handle a high polygon model without causing an unworkable lag, then stick with your normal methods of working. It is only system lag during modelling that, in my opinion, should lead to anyone reducing polygon counts in their models. I find that with an AMD64 3200+ with 1Gb RAM and an nVidia 6200 card, I don't suffer any noticeable lag until I pass the 200,000 polygon level, and it is still workable upto 400K. Of course, the way to get around this is to make your model in sections, and then merge all these sections for the final render. That way your system only has to handle the polygons of the part you are working on, and not the whole model, all the time. Of course, if you hide sections of the model, this is also the case, as it is only the render to screen that casues the lag, and I have, in the past, successfully handled a 2million polygon model on a system about half as powerful as the one I currently use.

So that's my five cents worth (well, more like 10 dollars worth really lol).

[shpangler 19]

Thanks for the advice.  I have just a quick question.  When it says you have a polygon budget of 10,000:  does that matter or is it just a default number used by Gmax?

[onlyplace4 603]

The budget is an arbitary figure set as a default by the program. You can set this to anything you like, it is simply there as a means to remind you of any budgets you have set yourself. You can safely ignore it.

[cogeo 960]

Yes, converting a mesh to poly doesn't affect the render quality, but as onlyplace4 suggested, they're no longer easily editable. But this can save you hours of rendering time, if your BAT is massive. I usually have by BATs saved as meshes (and work on them), then I convert to polys immediately before rendering.

The budget is arbitary, and it only affects the rendering time not the ingame behaviour, which is affected only by the BAT's size and the shape and size of your LODs. The actual 3d object rendered ingame is the LODs (usually a box).

[SimGoober 2,350]

another 2 cents here... by the time this thread is done we might be able to afford a gumball...

Some of my models have had 1 million plus polys. It certainly affects render time, but doesn't kill it by a long shot. The three things I have found that most affect renders are :

1) Building size. 10,000 polys or 1,000,000; big buildings are ... big. They take longer to render.

2) LOD complexity. a simple box LOD will render faster than a more complex one. A more complex one will also increase the file size of the rendered model file. Sometimes by a large amount.... 100kb went to 450 kb in one experiment I did.

3) Image (textures) quality. This one is overlooked a lot, but I have found that pretty low resolution JPG files work best 95% of the time. Rarely do I use anything besides jpg, and generally 400x400 is "big" for my textures. In photoshop, I save them as medium (5) quality.

Adding nightlights naturally increases render time, as you add more fsh files for the nitelites.

As has been said above, there is no one thing that affects render time more than others, they all work together. Lower poly counts usually help, but it's not always that simple.