Oh I know how to do it vaguely, it's not too different to expert compile mode.
I'll download a tool and have a bash with it.
:downs:
Tried the batch compiler, didn't help.
I'll give this vbsp a try when next I can spare a couple of hours.
[QUOTE=chris0132]How incredibly stupid, virtual memory is ideal for something like compiling, as it doesn't need a good transfer rate.
I could try that I suppose.[/QUOTE]
On the contrary, the compile tools do TONS of heavy 3D math and radiosity math which requires lots of computational power and speed. The tools probably hate swapping because swapfile is hundreds of times slower than system memory.
I compiled a version of gm_flatgrass that takes up the entire editor in all 3 axises. It took 5 minutes with hammer open.
[QUOTE=GiGaBiTe]On the contrary, the compile tools do TONS of heavy 3D math and radiosity math which requires lots of computational power and speed. The tools probably hate swapping because swapfile is hundreds of times slower than system memory.[/QUOTE]
I know but the write speed shouldn't really be an issue, it's inconvenient to have to wait longer, yes, but it should also be expected when you're compiling something.
A game is rendered useless and unplayable if you don't have a fast memory speed, a compiler just takes longer.
Heh, I just mentioned that you are the same guy I asked about VMPI compiling a while ago via Email :D
Your tools are working real well, this reduces rp_sunshine compile time hell alot.
Might just cripple your fps in the process though stene...
In fact I am not so sure if it will now. I would appreciate it if you could do a comparison for me?
[QUOTE=Stene]Heh, I just mentioned that you are the same guy I asked about VMPI compiling a while ago via Email :D
Your tools are working real well, this reduces rp_sunshine compile time hell alot.[/QUOTE]
Faster compile time doesn't mean it's better.
Well, I don't know does this affect framerate in any way.
[QUOTE=Stene]Well, I don't know does this affect framerate in any way.[/QUOTE]
It would depend on how your map is set out. If you have a map like flatgrass, where you always see all the vis leafs, then no it wouldn't affect the FPS.
But in a map with hallways, buildings, open areas and closed areas, it would probably show a large difference.
As far as I know, the whole thing can be replicated with hint brushes. This basically puts the optimization of large maps into your hands, instead of the hands of their crappy automated tools.
If you know what you're doing, you can make it have just as good FPS using this compiler and a lot of careful placing of hint brushes. That takes time though. It's up to you to choose if it is worth the time and effort. (I'd say so.)
So, should I optimize the map like Hometown1999, that I fill the whole map with just Hint brushes on top of each other?
No, that was terrible optimisation :(
[QUOTE=HiddenMyst]It would depend on how your map is set out. If you have a map like flatgrass, where you always see all the vis leafs, then no it wouldn't affect the FPS.
But in a map with hallways, buildings, open areas and closed areas, it would probably show a large difference.[/QUOTE]
See now I'm not sure about that.
Vvis does a lot of work for you, but it's also extremely dumb at times.
A mapper who understands visleaf theory should be able to replicate visleafs with hint brushes where neccesary, and I don't think this stops world geometry from generating vis planes, it just means hammer doesn't automatically snip everything into blocks when there's nothing there.
[b]Edit:[/b]
[QUOTE=metallics]No, that was terrible optimisation :([/QUOTE]
I can actually see the point in that, if you have buildings of varying heights you would want several vertical layers which would be shown/hidden based on the height of what is blocking your view and how close to it you are.
It makes perfect sense to me, although it would send your vis compile time through the roof.
If it is done right, like you say yes, but the placement was horrible in hometown if I remember rightly.
I mainly say it because I did it in a recent map to improve framerate.
It worked quite well actually, but I think it might be causing my vvis crashes.
Mind you I also think they occur without the hints in.
Only 1 way to find out :)
Yeah, compile for another two hours.
Which I really can't be arsed to do.
I'll just give this bugger a whack next time I compile and delete most of the hints.
Couldn't you just visgroup them all and then hide them? would save you having to put them back in or resaving the map...
Is this good for rp maps?
[QUOTE=metallics]Couldn't you just visgroup them all and then hide them? would save you having to put them back in or resaving the map...[/QUOTE]
They are visgrouped.
[QUOTE=oskutin]Is this good for rp maps?[/QUOTE]
Not really. You can use it to quickly test an RP map but you shouldn't use it for a final compile.
I tried using it to fix one of my maps, didn't work.
Did help the vis compile though, as you said.
As a question, do you know whether or not the limits on the compile tools can be lifted? Or are they engine limitations as well?
[QUOTE=chris0132]I tried using it to fix one of my maps, didn't work.
Did help the vis compile though, as you said.
As a question, do you know whether or not the limits on the compile tools can be lifted? Or are they engine limitations as well?[/QUOTE]
These limits?
[code]Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 1/1024 48/49152 ( 0.1%)
brushes 7/8192 84/98304 ( 0.1%)
brushsides 42/65536 336/524288 ( 0.1%)
planes 50/65536 1000/1310720 ( 0.1%)
vertexes 43/65536 516/786432 ( 0.1%)
nodes 27/65536 864/2097152 ( 0.0%)
texinfos 3/12288 216/884736 ( 0.0%)
texdata 3/2048 96/65536 ( 0.1%)
dispinfos 0/0 0/0 ( 0.0%)
disp_verts 0/0 0/0 ( 0.0%)
disp_tris 0/0 0/0 ( 0.0%)
disp_lmsamples 0/0 0/0 ( 0.0%)
faces 16/65536 896/3670016 ( 0.0%)
hdr faces 0/65536 0/3670016 ( 0.0%)
origfaces 6/65536 336/3670016 ( 0.0%)
leaves 29/65536 928/2097152 ( 0.0%)
leaffaces 16/65536 32/131072 ( 0.0%)
leafbrushes 18/65536 36/131072 ( 0.0%)
areas 2/256 16/2048 ( 0.8%)
surfedges 88/512000 352/2048000 ( 0.0%)
edges 57/256000 228/1024000 ( 0.0%)
LDR worldlights 2/8192 176/720896 ( 0.0%)
HDR worldlights 0/8192 0/720896 ( 0.0%)
waterstrips 0/32768 0/327680 ( 0.0%)
waterverts 0/65536 0/786432 ( 0.0%)
waterindices 0/65536 0/131072 ( 0.0%)
cubemapsamples 0/1024 0/16384 ( 0.0%)
overlays 0/512 0/180224 ( 0.0%)
LDR lightdata [variable] 416/0 ( 0.0%)
HDR lightdata [variable] 0/0 ( 0.0%)
visdata [variable] 44/16777216 ( 0.0%)
entdata [variable] 648/393216 ( 0.2%)
LDR leaf ambient 29/65536 696/1572864 ( 0.0%)
HDR leaf ambient 0/65536 0/1572864 ( 0.0%)
occluders 0/0 0/0 ( 0.0%)
occluder polygons 0/0 0/0 ( 0.0%)
occluder vert ind 0/0 0/0 ( 0.0%)
detail props [variable] 1/12 ( 8.3%)
static props [variable] 1/12 ( 8.3%)
pakfile [variable] 10016/0 ( 0.0%)[/code]
They're most likely engine limits or .BSP file limits.
You can go over the 100% limit for props, I think up to 200%,
Same with entdata
Infact you can with most as chris said.
[QUOTE=metallics]Same with entdata
Infact you can with most as chris said.[/QUOTE]
Which is why I'm curious as to whether or not the ones that stop the compiler from working can be lifted.
I don't know whether it's a value length limit, or whether it's an actual limit to how much the game engine can safely load in a map file.
If you use areaportals you could keep the number rendered at any one time below that limit quite easily, it's just loading them all into memory that I wondered about.
[QUOTE=chris0132]Mainly the vertex and plane ones, most of those I can go over quite happily without causing problems, vertex and plane limits make the compiler refuse to operate though.[/QUOTE]
The vertex/plane limits are the ones most likely to not be changeable by the compilers.
If you have to have too many vertices, a better solution would be to [url=http://developer.valvesoftware.com/wiki/Optimization_%28Geometry%29]optimize[/url] your map.
Sorry, you need to Log In to post a reply to this thread.
