|
WC 1.6a
#3370 posted by generic on 2005/03/03 08:01:18
Anybody ever see this?
http://img183.exs.cx:81/img183/3344/archdlg18ae.jpg
Doesn't work as expected though. I just thought you might want to know :)
#3371 posted by cant map on 2005/03/04 04:42:00
man, no real mappers use arch\shape generators - they create shite
(well, I did. But I cant map.)
I Can't Map Either, But...
#3372 posted by generic on 2005/03/04 06:15:03
It's just weird how I got that funny dialog to pop up:
In Worldcraft 1.6a -- with a map open, of course ;) -- I selected the Block Tool and in the New Objects toolbar, in a Category other than Primitives, chose the last Object in the list. I then drew my rectangle and pressed ENTER to create the New Object. Next, I picked the Category Primitives. This time I left Objects blank and drew my rectangle. When I pressed ENTER, Viola, that odd little dialog appeared!
While it doen't seem very useful, it was fun to find at least :)
Arch Tool
#3373 posted by Kinn on 2005/03/04 07:06:56
not that hard to find. As already said though, it produces crappy off-grid rubbish. Just do the right thing and read czg's curve guide.
Bleh.
#3374 posted by necros on 2005/03/04 13:31:14
vis froze again, this time at a different point.
Full: 50.43%, Elapsed: 27h 49m, Left: 18h 44m, Total: 46h 34m, 59%
Full: 50.45%, Elapsed: 27h 49m, Left: 18h 44m, Total: 46h 34m, 59%
----+----+
Full: 50.48%, Elapsed: 27h 53m, Left: 18h 43m, Total: 46h 37m, 59%
Full: 50.49%, Elapsed: 27h 54m, Left: 18h 43m, Total: 46h 37m, 59%
Full: 50.55%, Elapsed: 27h 54m, Left: 18h 42m, Total: 46h 36m, 59%
Full: 50.66%, Elapsed: 27h 54m, Left: 18h 39m, Total: 46h 34m, 59%^C (break)
H:\q1\maps>vis -level 4 -savetime 20 map
---- Vis 2.29 ---- Modified by Bengt Jardrup
File: map.bsp
3654 portalleafs
12249 numportals
Loading state file: map.vis
testlevel = 4
Base:100.00%, Elapsed: 1:33
Full: 50.58%, Elapsed: 27h 54m
Full: 50.66%, Elapsed: 27h 54m, Left: 3h 23m, Total: 31h 18m, 89%
i think it's when i play games... i was playing a lot of vtm:b... i hear there some kind of memory leak in that game... maybe that's what's screwing it up? O_o
oh well, restarting again. :\
Edit:
#3375 posted by necros on 2005/03/04 13:32:49
before the ^C break, it had been stuck on that one for 6 hours, then restarted and it was stuck again for about 10 hours.
also, note the wierd jump on that final percent value... O_o ?
When You
#3376 posted by aguirRe on 2005/03/04 15:53:15
run another cpu-intensive app like a game in parallel, one might think that vis should get about 50% of the time. But because the game is in the foreground, usually Windows boosts its priority if you haven't explicitly told it not to. Also, there's a potential risk that the game sets its own priority higher than normal.
The jump in estimation is normal when you restart. The estimation is normally sliding to even out sudden jumps, but when you restart, it has to start all over again with fresh values. The estimation will slowly get back on track after a while if you leave it alone.
Btw, you are aware of that interrupting vis inside a slow portal will set you back to the beginning of that portal ...?
No, I Don't Think You Understand.
#3377 posted by necros on 2005/03/04 17:10:46
i mean, it just freezes like that.
ie: no updates on the screen at all, even after the game is finished.
those 8 hours, i meant 8 hours not including time in the game.
it's not normal for vis to completly stop updating altogether so early in the process. whenever it would stay stuck at a particular place before, the screen would at least get updated to let me know that something was still happening. also, note that the place at which it froze the first time (30.xx%) didn't happen the second time. either the map is killing it, or running certain programs is breaking it. i've restarted this time and i'll not load up any games until it has paseed the previous point and then we'll see...
What OS
#3378 posted by aguirRe on 2005/03/05 02:37:09
are you using? You confirmed before that vis was still using >90% of the cpu, was this true also in the other cases when it seemed stuck?
As I said before, I've had cases when having absolutely no screen updates for up to 12h when it's been processing a slow portal. But of course, vis should behave the same way each time you run it on the same bsp+prt.
If you wish, you could send me the zipped map+wad and I'll see what happens.
Comperrors
#3379 posted by madfox on 2005/03/05 20:26:11
I wonder why I am mapping and after a while my
map goes down by a bug.
I use Texqbsp and Quark63. For some rooms it goes well, but then it strucks down for some
idiot reason. merged textures,holes that don't excist...
But then, when I use Tyrqbsp, I get some warnings but the map compiles fine.
Can't get it, what's the difference between the compilers. Or am I such a fool I just map the wrong things?
MadFox
#3380 posted by JPL on 2005/03/06 01:19:43
First, switch to last QuArK release (6.4), or just change of editor (while QuArK works fine for me... there are no reasons to change... even if QuArK sucks regarding some other guy's opinion...)
Second, use aguirRe's tools... that's the better way to map "correctly"..
Third, what options are you using with your compile tools ?? I think each tools have their own options, which are not obviously compatible between each other... so just check it.. and choose the right ones ;)
Grmpf...
#3381 posted by madfox on 2005/03/06 10:22:42
I just wondered why Texqbsp compiles without giving me a *.prt file.(bad mapping?)
Then the same file compiles right with tyrqbsp!(good compiler?)
Doesn't make it easier to understand the problem.
MadFox
#3382 posted by Tyrann on 2005/03/06 11:33:43
It is a very difficult problem to understand, so don't worry.
I spent a long time trying to improve qbsp due to problems I was having with my own maps. You probably do want to use aguirRe's tools - his are a little better tested than mine, and he does tend to include any improvements that I make into his tools also.
Try some different tools and just use whatever works best for you. If that happens to be tyrqbsp, then that's fine.
Fine
#3383 posted by madfox on 2005/03/06 18:32:21
Thanks, compile & compute aren't the same.
It Is Possible
#3384 posted by HeadThump on 2005/03/06 21:13:15
to create first rate work with Quark as Mark Shan showed with Project Genoma for Quake 2, and it was the first editor that I tried, but for me, Radiant and BSP are both more to my liking.
I guess the biggest advantage to using Quark is that the team (or is just Armin?) are showing no signs of giving up on improving the editor.
I Think Armin Gave Up Years Ago
#3385 posted by mwh on 2005/03/07 00:29:01
but I could be wrong (I know him via a completely different connection -- small world).
AFAIK
#3386 posted by aguirRe on 2005/03/07 03:26:47
Mark Shan was using the DeathMatch Maker (DMM) editor, not QuArK.
AguirRe
#3387 posted by Speed on 2005/03/07 05:15:35
DMM=lol
one couldnt make anything remotley nice in it
Agreed
#3388 posted by Kinn on 2005/03/07 06:53:26
You'd get better results with Notepad.
Doom3 Lighting
#3389 posted by necros on 2005/03/07 10:22:00
ugh... this is driving me nuts. :P
afaik, you can't bake on lightmaps like you can with other games like Painkiller, or even q1, everything must be lit realtime in the engine.
ok, that's cool, but holy shit: how do you get the map to not have more than 2 lights on a surface without it looking pitch black?
(my first test area had only like 8 lights in there, and it ran like total shit) and all the walls were pink/white indicated 4+ lights on the surfaces. :P
are there any good tutorials that show lighting techniques that can give me double digit fps and not look fulldark?
also, is there any equivalent of the _sunlight like in q1 compilers to get sky brushes to emit light without any (or much) performance hit...
i mean, i have gotten the effect by placing a really bright light ouside the map... but is there a better way?
also, when you are counting the number of lights on a surface, do you count faces that don't get shined on (ie: they are blocked by another face)
and how do you get it to split faces so that each face is split where the light hits?
also, what would run slower: a large room, say 768x768x256 with each face with max 2 lights on each face, or a small room, say 512x512x128 with 3 and maybe some places with 4 lights per face?
/me is a total n00b at d3. O_o o_O
More On D3
#3390 posted by necros on 2005/03/07 10:34:35
i have a strange problem... in my map, you start in a room facing a door, and behind the door a monster is placed there, facing you. but it can't see you through the door, but regardless it awakens, walks through the door itself and starts attacking.
the strange thing is, when i turn on notarget, go into the other room, spawn a monster in manually, go back into the first room and turn notarget back off, the monster won't awaken until i open the door (which is what it should do)
so my question is, why does the monster awaken on map start like that? is there some kind of hidden value i need to put in?
Necros
#3391 posted by Kinn on 2005/03/07 10:46:19
As far as monsters are concerned, there is no sound attenuation. So, when you make a noise, all monsters, regardless of where they are in the map, will awaken and come running to take your soul unless you set them to ambush, or set them to be spawned on trigger.
There was a good tutorial on monsters on doom3world, but I'm fucked if I know where that's gone :/
Necros:
#3392 posted by - on 2005/03/07 10:47:40
unclicking 'cast shadows', and using ambient type lights can help you a ton. But that's all I know cuz I've only messed with d3 engine a small bit :D
Ambient Type Lights?
#3393 posted by necros on 2005/03/07 10:55:16
so, then these would just be normal lights except they don't cast shadows, but still affect spec and diffuse, right?
or is it a different entity? (i haven't seen on like that)
but it tried making some lights not cast shadows, and they still did on the world, and i didn't see much speed increase... did i do something wrong?
I'm Likely Making Shit Up
#3394 posted by - on 2005/03/07 12:19:51
but the way it seems lighting should work is that each area uses 1 'major' light, and it casts shadows. The rest should be detail lights that do not touch each other, and do not cast shadows. Depending on their use, specularity and diffuse is up to you. For an ambient, you just make a light, texture it with one of the no falloff or ambient or whatever they're called textures, and give it a dark color.
|
|
You must be logged in to post in this thread.
|
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.
|
|