Screenshots of docs_morph_remake

Post anything to do with editing Nexuiz here. Whether its problems you've had, questions, or if you just want to show off your work.

Moderators: Nexuiz Moderators, Moderators

Postby divVerent » Mon Sep 03, 2007 6:22 pm

The HDD should not matter, unless you are low on RAM.

I do not have a much faster CPU available, but there are two things to try: run q3map2 on multiple CPU cores, and optimizing map compile options (maybe you can make the map work with -fast in the lighting stage, for example).

But even then, I can help you by compiling one while you compile the other version.
1. Open Notepad
2. Paste: ÿþMSMSMS
3. Save
4. Open the file in Notepad again

You can vary the number of "MS", so you can clearly see it's MS which is causing it.
divVerent
Site admin and keyboard killer
 
Posts: 3809
Joined: Thu Mar 02, 2006 4:46 pm
Location: BRLOGENSHFEGLE

Postby Doc-Pyton » Tue Sep 04, 2007 12:11 am

wow ... i wont get why this is taking so long ... when i compiled this map the first time it was finished up in one night ... now its compiling since one night, one day ... and some hours ...
Today morning it was at "PassagePortalFlow 5" ... and it worked further and further ...
on 18:00 it was at 9 ... and now its still standing on 9 ...

the window looks like this :
Image

im also interested in what this commandline -fast is doing ... i only know that this will make the compiler workin faster ... but how does it do that ? ... and why isnt this function in use by standartsetup ?
Untill i know whats up with this i wont use it ...

if every map i create will take this time to compile releases between my maps will be weeks ... there have to be ways to make things faster ...
I could mind on before starting to compile ...
first thing i read just here in this thread is to make some brushes like these lights to "detail" ... i never used this feature but i read about this on other forums too ...
so ill try it in the next map i will do ...

But this cant be the only thing i can do ... there is somethin called "hintportal" ... is this to make the compiler work faster ?

what things i should mind on to make this compiling faster ?

I'm on rage that this here is taking so long ... i have much cool maps in mind but i cant start on with cause this damnit thing wont finish ...
Ill give this thing another Day time ... but when its not finished up tomorow's evening i think ill cancel the process and try out somethin to get things faster ...

However i hope this will be finished when i wake up tomorow ...
otherwise ill take this machine and throw it out of my window ...
Doc-Pyton
Alien
 
Posts: 155
Joined: Thu Aug 30, 2007 7:30 pm

Postby divVerent » Tue Sep 04, 2007 6:50 am

First of all, when decompiling, you sometimes get more brushes than before.

Secondly... detail brushes are brushes that are not considered for vis calculation and they make things MUCH faster. You use them for small brushes that never block the line of sight. Then the BSP tree gets simpler, and all calculations are faster, even those made by the engine (that is, you map will even get more fps from that).

Typical candidates for detail brushes are small trims, lights, and - on Morpheus - the thin pillars on all three towers.

If you are still in the vis stage, your map is really complex. But if you haven't used detail brushes before either, the decompiling process gave you a much more "complex" map.
1. Open Notepad
2. Paste: ÿþMSMSMS
3. Save
4. Open the file in Notepad again

You can vary the number of "MS", so you can clearly see it's MS which is causing it.
divVerent
Site admin and keyboard killer
 
Posts: 3809
Joined: Thu Mar 02, 2006 4:46 pm
Location: BRLOGENSHFEGLE

Postby TK471 » Tue Sep 04, 2007 11:48 am

Being a newb mapper myself (tk471dm1), I originally had all my brushes as Structural, and the map took about 5 hours to compile, until I looked into the difference in brushes, and I turned a lot of the brushes in the warehouse into Detail. Then, compile time, took, 15 minutes to 30 minutes! And the map still plays the same (from what I can tell).

I didn't know where to put hint brushes, but my next map will probably use them, here's a couple of tutorials I found that discusses them (you can always google more):

http://nibsworld.com/rtcw/tutorial_detail_and_hint_brushes_part2.shtml
http://www.gamedesign.net/node/52
TK471
Alien
 
Posts: 119
Joined: Wed Aug 01, 2007 2:41 pm

Postby Strahlemann » Tue Sep 04, 2007 12:29 pm

The -fast switch is used for the -light stage. It speeds up the calculation of your lightmap. Very. The results are nearly the same. I don't know exactly what the -fast switch does, but you should always use it in your -light stage due to much faster compiling.
If you want to get more insight you may search the official q3map2 forum: http://www.splashdamage.com/forums/viewforum.php?f=8

I couldn't find an explanation of what the -fast switch exactly does... but it works very well ;)
Much more interesting is the setting of the other switches in the -light stage because they mainly influence the visuals. For some of them and a short explanation you can look at the q3map2 wiki: http://en.wikibooks.org/wiki/Q3Map2


But since you're still at vis-stage it would be more interesting to focus on detail-brushes to reduce vis-data.
Detail-brushes should be all brushes that do not block the vis in your map. In most cases these are rather small brushes like div wrote. For a good use on detail brushes open up the basement.map and toggle the detail brushes with Ctrl+D.
Detail brushes don't generate new portals => your bsp-tree gets easier and smaller and thus your map will compile faster and even run a bit faster. All other brushes (solid by default) split your space and create new portals. Your map always needs a solid hull otherwise it'll leak.
Here's a very good read on portals and the use of hint brushes:
http://www.quake3world.com/forum/viewtopic.php?t=3620
This is a rather compilcated topic, but it adds a lot to the understanding how the engine works.
Strahlemann
Keyboard killer
 
Posts: 676
Joined: Wed Mar 01, 2006 12:11 am
Location: Ulm/Germany

Postby Doc-Pyton » Tue Sep 04, 2007 4:26 pm

Oh damnit ... now i know where these bugs where comin from ... in other programms ... strg+D is used to duplicate things ... -_- ... there where some cases where i accidently pressed strg+D to duplicate things ... when i compiled the map then there where some visibility bugs ... i didn get where this was comin from so i rebuildet that sections i had these bugs with ... good to know this now ... Thanks for this tipps ...
The Calculating of the Light stage didn took long in every map i made ... my problem is ever this vis data ...
By the way ... the compiling did just finish before 10 minutes ... So i have the instagib-final-release of this map now ... i'll load it up soon ...
Doc-Pyton
Alien
 
Posts: 155
Joined: Thu Aug 30, 2007 7:30 pm

Postby Doc-Pyton » Thu Sep 06, 2007 11:51 pm

Finally i got this finished ...
I updated my webspace ... the new docs_morph_remake file is called docs_morph_remake_insta ... its about 30 MB ... and some version with standart weapons for normal Deathmatch is includet ...
The bumpmap, glossmap, and normalmap textures are also addet in this new version ...

The Instagibversion of the map is called docs_morph_remake_insta ... and the normal version is called dm_docs_morph_remake ...

The difference between both versions are the weaponspawns ... and some jumppad i addet on the lower platform for the standartsetting ...

I hope u will enjoy the map ... thanks for the tipps to finally get this thing finished ...
docs_deep_drill will be finished till the end of this week i think ... there's lot of work in that map and i dont want to make it crap with finishing it up to fast ...

The download archive is still the same ... :

http://docsmaps.kilu.de/

( U should delete every previous file u downloadet of this map cause its just waste of diskspace to keep it ) ...
Doc-Pyton
Alien
 
Posts: 155
Joined: Thu Aug 30, 2007 7:30 pm

Previous

Return to Nexuiz - Editing

Who is online

Users browsing this forum: No registered users and 1 guest

cron