My render problem with this map (pics included)

[pmweb9873]

Okay, here is the map I'm working on.

So my problem is now that its just taking forever to render the lighting. It spends a ton of time on the VVIS part of the render. Without putting tons of HINT brushes all over the map it takes about an hour to render. Its a tiny map. I've made UT2004 maps that were 20 times the size of this one, had way more prefabs and other stuff and took no more than 10 minutes to render at most. Is there something I need to do extra besides just HINT brushes? Any recomendations on getting this thing to render faster would be appreciated. Also, I want it to render with the lighting. I know how to get it to render without lighting and go fast but I want it fast with lighting applied.

Thanks!

 

[Lobster]

UT2004 doesnt compile the same way, BSP based engines always have long compile times, esspeacialy when your making so much detail using brushes, as opposed to props,

 

[Johan_Tayn]

looking good, though..

 

[pmweb9873]

UT2004 doesnt compile the same way, BSP based engines always have long compile times, esspeacialy when your making so much detail using brushes, as opposed to props,

I don't really consider that a real reason why my map should compile that slow. You guys have any ideas on where I should stick some other stuff that might help the compile time?

 

[rkef]

I haven't created anything that detailed yet, so I can't say whether it's normal or not, but one thing I wonder about is whether those chairs and tables are props, func_details, or brushes? If the latter, I believe that would cause huge problems.

Sorry, all I can think of atm.

 

[Ti133700N]

Yes i'm thinking the same, if the chairs/tables are brushes, it's gonna take a while to compile. Make them func_details. Also, make sure you do not have intersecting brushes or textures tiles less than 0.5. You can apply the null (might be a better texture for this but i'm not sure) texture on the faces that will never be seen. And on the faces that will hardly be seen, up the texture scale (more than 1 if possible).

 

[FragileX]

Maybe it will work if you turn of .vis when your testing and use nightvison googles. Then turn on vis when you finished.. Maybe it will go faster that way..

 

[rkef]

Maybe it will work if you turn of .vis when your testing and use nightvison googles. Then turn on vis when you finished.. Maybe it will go faster that way..

Interesting idea, but there's always "mat_fullbright 1", which will illuminate the entire level.

 

[pmweb9873]

Yeah, and mat_fullbright 1 looks horrible. My level is built around the effective use of lighting and I know its going to be difficult later to place lights if my alterations are going to take 4 or 5 hours to view so that I can render the map.

 

[socK]

func_detail any brushes that arent the box the level is in itself. (Unless you need to block alot of geometry behind it.)

 

[Demonmerc]

can some experienced mappers confirm this?

 

[socK]

func_detail does not block vis or cut brushes. It is also ignored by the vis process. (I think... it's ignored by something, and detailing correctly will drasticly cut down compile times)

 

[Sean]

Here's your problem, IMHO: There is not a single point of your map that is not visible from any other point. The entire thing is one big open box. This is bad mojo for the renderer, and really not a good idea in terms of gameplay. If you're going to be fragging in it, put up some cover. It'll help your compile times, and our framerates.

Also, this may sound dumb, but that seems like a lot of props. It may be realistic, but it looks too cluttered to me.

EDIT
Two more things: Big levels always take a long time to compile. This isn't unreal, this is quake-style. Get used to waiting. Check your level for a leak, while you're at it. Not likely, considering the whole box thing, but it's possible.

 

[JFry]

Sean is correct about the openness of the level being a cause of the long vis time. Basically when vis runs it draws a line from each face to every other face it can see, and in your case, that's a hell of a lot of lines. However if you placed some vis-blockers (must be world brushes) it would shorten vis time drastically.

Also func_detail, func_wall, or any entity for that matter will not split faces on a world brush, but it will split faces on another entity. For example say you wanted to connect a pipe to a wall and both were made of world brushes, it would split the wall into as many faces as the pipe has. However, if you were to place a flange in between the pipe and the wall and turn it into a func_wall, no faces would be split.

Doing this is a good idea because not only will it be less work for vis, but it will render in-game faster as well. Hope that wasn't too complicated, nice looking map by the way.

 

[thereisaspoon]

are those prop_ models or are they bsp prefabs (there is a difference)? If they are prefabs, that's whats raping your compile times.

and lol, ut 2004 is a bsp engine, pretty much all game engines are bsp.

Also what kind of lighting r u using? make a skybox with a light_environment (which i belive is the equivalent of sunlight in ut2k3/4)

 

[pmweb9873]

I'm not using a light enviorment. I had one but I took it out because I felt the lighting looked better without it. So I am using individual lights to light it. I also figured out I can get the lighting to render if I just set VIS to render on FAST. It works fine that way to get things looking alright although I don't think the map is being optimized. Also, the chairs are all prop_physics and they are entities so they aren't made from BSPs. I actually thought that would mean that they would render faster than BSPs would. I am also trying to go for the cluttered look for that eating area as well since thats how is almost looks although I need to go in and actually design the proper tables and chairs for the place since the colors dont match and the chairs are too small.

 

[Carbon]

You aren't using a light environment? How many lights are in there? No wonder it takes forever to compile. Rendering heaps of lights takes ages normally, but when they also overlap in their light areas it will take even longer to calculate AFAIK. I seriously advise you use a light env, and probably about only 4 lights in that large room to light it properly.

 

[pmweb9873]

I put a light for each ceiling light because I thought that would light it more accuratly.

 

[Carbon]

So you have 10 overlapping lights and thats only in that main room? There is little point in having that many lights in there, since there is little to no detail on the walls its not like the shadows will look incorrect if you use 4 or maybe 6. You will obviously have to fiddle with the brightnesses to make it look right tho. And seriously, use a light env to light the outside, if you want a less consistent lighting scheme use a very dark light environment and then add small lights like park lamps around the edges or something.

 

[pmweb9873]

Hmm.... will the light enviorment light the inside of the building as well? How do I get it to cast shadows from the buildings and stuff?

 

[Carbon]

It will do all that automatically. And so long as there is a roof on the building the light wont get in there. You will need to set the angle to -30 (if its sunset) or -60 if its more day time (the angle is measured from the horizonal) and then choose the direction from the little compass like thing.
Light will come in the windows, but thats realistic anyway.

 

[Sean]

and lol, ut 2004 is a bsp engine, pretty much all game engines are bsp.

I used to map with UT, and as I recall, the compile times were virtually non-existant compared to Quake's. Not sure about 2k4, though...

I don't think VIS has anything to do with lights. Cutting back light entities will help your RAD time, but if that's not causing you problems, why bother? Do add environment lighting though, it'll look real purty.

Two final points: Again, get rid of some of those physics props. It may not help your framerate any, but if you're planning on making this a multiplayer map, it _will_ improve ping times. And you're map's still too open, IMHO.

 

[Shinobi]

vis is going really slow and you used to map in UT2k4?

my guess would be you have overlapping brushes,, if there's still a -brushunion switch in CSG then I suggest you use it

 

[Sean]

Oh, snap! One more thing: there are a lot of brushes in those windows. Tone that down, make it a texture or something. Remember: when two brushes connect, they split! Turn on mat_wireframe while testing next time, and you'll see what I mean.

 

[pmweb9873]

Wow, i looked at my map using that mat_wireframe and you are right. There are a gazillion of extra triangles that totally don't need to be there. I have no idea why they are there. I really do not want to go in and start seperating all of my brushes by one unit because that is really going to mess up my grid settings. The lowest detail I have in my map is down to 4 units. Is there anyways I can get around having to go lower than that? I've learned through my mapping expiernce with UT that I start to missalign things if I go smaller than 4 units. I also don't want tons of gaps all over my map so I don't know how I'm going to get around this.

Yeah, thats what it looks like. How do i get rid of all those extra triangles without having to seperate everything?

 

[Ti133700N]

Oh and I forgot to tell you to make a gap between those horizontal things and the ceiling (1 to 4 units will be alright).

 

[Sean]

Do func_details cast shadows?

 

[tank]

besides the extra triangles in your map that shouldn't be there...try using nodraw texture for anything that the player will not see...this relieves alot of burden off the renderer...i am using it with my map (twice the size of yours) only 5 light sources... it compiles in 20 seconds (btw what system you running this on?)

grant it i dont have as much detail either though

Tank

 

[socK]

func_detail everything. (except the box the map is in)
If you want/need to block alot of triangles behind a wall or something, then keep it the same.

func_detail doesnt split brushes, yes it casts shadows and it doesnt block vis.

[edit] doesnt the engine cull faces that are in the void? Though there is still some spots a nodraw would come in handy...

 

[pmweb9873]

Yeah, every face that doesnt show has the no-draw applied to it. That seemed to help a lot when I did that a while back. I'm going to add the light_enviorment in a bit. I've managed to cut down my compile times but I'm running a P4 2.4C, 1GB ram, Nvidia Geforce FX 5900 128mb graphics card. I'll try that func_detail tonight as well.

 

[pmweb9873]

Okay, new problem! Don't you guys just love this. Alright, how come the leaves on the trees dont appear? I'd really like to have green trees instead of dead ones. Btw everyone thats helped me so far, much thanks!

See my problem? It looks so dead! It supposed to look somewhat dead but not that dead. I'm going for a rainy look. Oh, btw, rain will be one of the feats I will tackle next. :rolling:

 

[pmweb9873]

Also, I know the map is really really open but the reason for that is this place actually exists and that is how it really is. If I was mapping just for a regular map I would realize this would seem way way too large but for this map it needs to be. Besides, its so much more difficult to map a place that actually exists well than to just make something up in my opinion and make it look good..... but then again that just my opinion