Posted by reaper47 on Fri Nov 3rd 2006 at 10:12am
? quote:
I used all the optimisation techniques with the exception of occluders and areaportals.
Probably I got carried away by this quote. midkay is right, if there's anything un-func_detailed that could be func_detailed it's probably the cause.
Posted by midkay on Thu Nov 2nd 2006 at 11:18pm
Is that necessary? I mean - clearly the problem is Vvis taking forever computing visibility between leaves. Why's that? Clearly, too many leaves. Probably several un-func_detailed brushes at odd angles and high vertex densities. So what'll an error check do? You and I know the problem, it's no mystery - now you use glview and func_detail to fix it.
As well as that tutorial, that can be helpful
Posted by reaper47 on Thu Nov 2nd 2006 at 10:53pm
I quickly entered this in the error machine and it gave quite a few ones. Although nothing that's usually dangerous, it's definitly worth checking. A general error check in hammer (alt-p I think) would be the first thing to try. Then try to use the cordon tool to compile only parts of your map. Maybe you can find the part that's causing problems this way!
But it's true a simple error either makes your compiles crash completely or only adds little to the compile times. Although I'd call 35 hours a crash (MAN!) checking out the mother of all optimization tutorials a second/third/tenth time is most promising.
You can't wait 2 days for every little compile. I feel with you, though!
Good luck!
Posted by midkay on Thu Nov 2nd 2006 at 5:57pm
I've gone from 7 and a half hours to 30 seconds.
Learn func_detail and use glview. You must have some complex geometry that's really causing vvis some pain. Vvis shouldn't take more than around a half-hour at most (a few minutes in most cases, if you optimize carefully).
No single error would cause a 35-hour compile. That is literally around a hundred times as long as it should take. Search Valve's developer wiki for glview and func_detail, and start to use them.
As finger suggested - posting the VMF would certainly help if you need or want more in-depth help, but any complex geometry in your map should be func_detailed.
Posted by Finger on Thu Nov 2nd 2006 at 5:29pm
If you are comfortable with offering your vmf file, it would be good to get some experienced eyes looking at the actual construction. It's hard to tell what's going on with a few screenshots and compile log.
Also, you should relegiously use func_detail to help control Vis. Any brush that isn't used to occlude should probably be turned into a func_detail. You would be amazed at how much difference that makes in compile times. I've gone from hours to minutes, simply by optimizing with func_detail. Be careful though, func_detail brushes don't occlude and they don't seal the world.
Posted by lamellama on Thu Nov 2nd 2006 at 12:12pm
hehehehe yeah
here is the vbsp:
Loading C:HL2MODDM Mapmapsdm_defenestrate.vmf
fixing up env_cubemap materials on brush sides...
0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6...7...8...9...10Processing areas...done (0)
Building Faces...done (0)
Chop Details...done (0)
Find Visible Detail Sides...
Merged 198 detail faces...done (0)
Merging details...done (0)
FixTjuncs...
PruneNodes...
WriteBSP...
done (1)
writing C:HL2MODDM Mapmapsdm_defenestrate.prt...done (0)
WARNING: node without a volume
Creating default cubemaps for env_cubemap using skybox materials:
skybox/sky_day01_07*.vmt
Run buildcubemaps in the engine to get the correct cube maps.
No such variable "$hdrbasetexture" for material "skybox/sky_day01_07rt"
Can't load skybox file skybox/sky_day01_07 to build the default cubemap!
Finding displacement neighbors...
Finding lightmap sample positions...
Displacement Alpha : 0...1...2...3...4...5...6...7...8...9...10
Building Physics collision data...
done (0) (298811 bytes)
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Compacting texture/material tables...
Reduced 3180 texinfos to 1724
Reduced 197 texdatas to 171 (7063 bytes to 6186)
Writing C:HL2MODDM Mapmapsdm_defenestrate.bsp
5 seconds elapsed
in the vrad there is:
3 degenerate faces
and 1 zero area child patch
that takes 7 minutes, 17 seconds
Many of the displacements cut into the water, should I cut them at the water line? Would it make a big difference? I'm busy today but maybe tomorrow i'll have a chance to try some things out
hehehehe yeah
here is the vbsp:
Loading C:HL2MODDM Mapmapsdm_defenestrate.vmf
fixing up env_cubemap materials on brush sides...
0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6...7...8...9...10Processing areas...done (0)
Building Faces...done (0)
Chop Details...done (0)
Find Visible Detail Sides...
Merged 198 detail faces...done (0)
Merging details...done (0)
FixTjuncs...
PruneNodes...
WriteBSP...
done (1)
writing C:HL2MODDM Mapmapsdm_defenestrate.prt...done (0)
WARNING: node without a volume
Creating default cubemaps for env_cubemap using skybox materials:
skybox/sky_day01_07*.vmt
Run buildcubemaps in the engine to get the correct cube maps.
No such variable "$hdrbasetexture" for material "skybox/sky_day01_07rt"
Can't load skybox file skybox/sky_day01_07 to build the default cubemap!
Finding displacement neighbors...
Finding lightmap sample positions...
Displacement Alpha : 0...1...2...3...4...5...6...7...8...9...10
Building Physics collision data...
done (0) (298811 bytes)
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Compacting texture/material tables...
Reduced 3180 texinfos to 1724
Reduced 197 texdatas to 171 (7063 bytes to 6186)
Writing C:HL2MODDM Mapmapsdm_defenestrate.bsp
5 seconds elapsed
in the vrad there is:
3 degenerate faces
and 1 zero area child patch
that takes 7 minutes, 17 seconds
Many of the displacements cut into the water, should I cut them at the water line? Would it make a big difference? I'm busy today but maybe tomorrow i'll have a chance to try some things out
Posted by reaper47 on Thu Nov 2nd 2006 at 11:59am
? quote:
Wait, are you compiling through Hammer? That might be adding an unessasary drain on the computer, slowing the compiles. If you aren't already, you might want to try looking for a batch compiler, like Nem's.
Maybe that does speed up compile times by a few percent but I doubt more than 5 or 10%.
35 hours, 21 minutes, 11 seconds elapsed
That's INSANE, absolutely insane! VIS is totally going totally haywire here!
Please post the vbsp log, too! Maybe something's wrong there.
Full VIS shouldn't take more than 5 or 10 minutes, usually.
Your VIS log doesn't look all that suspicious otherwise. Only the time is crazy.
Posted by G.Ballblue on Tue Oct 31st 2006 at 4:36pm
Wait, are you compiling through Hammer? That might be adding an unessasary drain on the computer, slowing the compiles. If you aren't already, you might want to try looking for a batch compiler, like Nem's.
Although, I would expect and HL2 map to take quite a while to compile. Mommamesa currently takes 7+ hours to compile, and that's for HL1 :/
Posted by lamellama on Tue Oct 31st 2006 at 12:50pm
To be honest I dont think there is much that can be done I think the large compile time is to be expected, it can maybe be reduced a little but making it take less than 30 mins would need massive changes to the design.
there is already a post about the same thing here: http://www.snarkpit.net/forums.php?forum=6&topic=3522&highlight=compile,time
I dont think the compile log is unusual except for maybe having high numbers. I'll delay the release a little while and keep going with some optimisation.
VVIS
1 threads
reading c:hl2moddm mapmapsdm_defenestrate.bsp
reading c:hl2moddm mapmapsdm_defenestrate.prt
1225 portalclusters
4289 numportals
0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6...7...8...9...10Optimized: 6871 visible clusters (0.00%)
Total clusters visible: 1005892
Average clusters visible: 821
Building PAS...
Average clusters audible: 1223
visdatasize:374561 compressed from 392000
writing c:hl2moddm mapmapsdm_defenestrate.bsp
35 hours, 21 minutes, 11 seconds elapsed
To be honest I dont think there is much that can be done I think the large compile time is to be expected, it can maybe be reduced a little but making it take less than 30 mins would need massive changes to the design.
there is already a post about the same thing here: http://www.snarkpit.net/forums.php?forum=6&topic=3522&highlight=compile,time
I dont think the compile log is unusual except for maybe having high numbers. I'll delay the release a little while and keep going with some optimisation.
VVIS
1 threads
reading c:hl2moddm mapmapsdm_defenestrate.bsp
reading c:hl2moddm mapmapsdm_defenestrate.prt
1225 portalclusters
4289 numportals
0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6...7...8...9...10Optimized: 6871 visible clusters (0.00%)
Total clusters visible: 1005892
Average clusters visible: 821
Building PAS...
Average clusters audible: 1223
visdatasize:374561 compressed from 392000
writing c:hl2moddm mapmapsdm_defenestrate.bsp
35 hours, 21 minutes, 11 seconds elapsed
