Jump to content

Home

Max_map_visibility


Vile

Recommended Posts

I KNOW DETAIL GOD DAMNIT, please dont insault me like that........

 

I need to make the visibility larger as I am making a flight map as in you fly around in ships and stuff, and the normal max visibility map size is WAY to small for a ship fight map, SO anyone know a way to change the value.

Link to comment
Share on other sites

If you ever say max_map_visibility in forums, expect that reply. It is the most common one, replying with capitals and "GOD DAMN IT" won't help. You didn't specify it was a large map and I am no trans-internet telepath. Any insult was unintentional on my part...your part however is a different story.

 

Worldspawn

key:_blocksize

value:16384 16384 16384

Link to comment
Share on other sites

Uuumm..Wade, is that not the default size that Radiant uses anyhow? Or do you ACTUALLY have to put the blocksize and number in? Making large maps like these cause framerate drops. Trust me I know what I'm doing. I think KOTOR map is about the maximum size you can go without the FPS dropping like a rock. Mr. Jay must have made some of his flat ground areas structural along with some structural asteroids. I don't think you can have PORTALS without them.......

 

Please let me know if anyone knows different.:rolleyes:

Link to comment
Share on other sites

Default block size is a mere 1024x1024x1024, you can imagine the vis data for large maps if it's split that frequently.

 

Trust me on this, large maps do NOT cause frame rate drops if done properly. It's a matter of finding a way of working around vis data and distance culling. On planet maps this is easily fixed by using a fog hull or large structures to block off vis. Space is harder. Kotor's problem is not that it is big, it is that there is no vis blocking at all and too many NPC vehicles. Vehicles that have effects such as rocket blasts are FPS killers. They rely of excessive efx file usage which pile on the CPU and the GPU.

Link to comment
Share on other sites

Originally posted by WadeV1589

Worldspawn

key:_blocksize

value:16384 16384 16384

 

Yeah, way to make the framerate fall through the floor, especially if you have a lot of brushes or terrain. Try something like 2048 2048 4096.

Link to comment
Share on other sites

Emon I know you're a resident expert but I have to disagree, I've used that value in my map which has detail galore but it runs at full FPS for me. This is even with terrain and models in view. I have an old GF MX420 that can push 90fps (my limit) on my map and anyone who knows me will tell you that I never spare detail.

Link to comment
Share on other sites

Originally posted by Emon

Yeah, way to make the framerate fall through the floor, especially if you have a lot of brushes or terrain. Try something like 2048 2048 4096.

 

I am agreeing with Wade here. It all depends on how your map is built. And having a lot of brushes actually will help (if they are structural) since they will add extra leaves and portals.

Link to comment
Share on other sites

It has nothing to do with leaves or portals. It has to do with collision detection. The engine only checks for an entity's collision inside the leaf nodes that it's inside. Wade, your map wasn't really that complex, I'm talking about when you start to get thousands of triangles in a leaf node. Besides, if you have fast CPU (video card is irrelevant), there isn't any way for you to determine if it would run worse on a lower end system, because r_speeds' output isn't going to change.

 

And making all your terrain brushes structural is, uh, kind of stupid. It'll take massively long to compile, and then the PVS will grow to be monstrously huge, which will eventually affect in-game performance.

 

Wade, your terrain wasn't very complex, it wasn't tessellated much more than the original Q3:TA terrain. I'm just saying when you get into having thousands of triangles in a leaf node, it does get slower. Collision detection will be happening against thousands of triangles every frame.

Link to comment
Share on other sites

In your first post all you said was "big blocksize is bad", which you have to admit is wrong to say. Your further explanation is far better..if not debatable still on some levels. You have to admit though your first post was far to vague to be correct on any real level.

Link to comment
Share on other sites

Originally posted by Emon

And making all your terrain brushes structural is, uh, kind of stupid. It'll take massively long to compile, and then the PVS will grow to be monstrously huge, which will eventually affect in-game performance.

 

I'm not talking about making the terrain structural. You can place large caulked structural brushes inside terrain. It gives you the necessary control to change the visdata of the map. If you got a lot of structural brushes your visdata should be split up nicely and you would get a good balanced portal size.

Link to comment
Share on other sites

caulk, antiportal.........wow am I confused :)

 

also my space_fight map has a fair amount of detail and is super massive in open size, for all that space fighting :), and I experence no slow down in compile times and no slow down in fps ingame so I dont see why Wade's block size thing is bad.

Link to comment
Share on other sites

It depends on the amount of crap you have in your level. In my Hoth map, I had terrain that was about 13K polygons for a single mesh, and I set the blocksize to be 32K, and the framerate went through the floor.

 

If you're doing a space level, you should probably set blocksize to straight 4096 when you compile, maybe 2048 (turn off vsync, and compare framerates on both). You can use a higher one for tests, because it'll compile faster.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...