|Posted by Scampie [188.8.131.52] on 2004/08/04 12:38:27|
|Figured with Doom3 out now, we should start a seperate thread from the other Doom3 thread dedicated solely to getting into mapping for it. Ask questions, post some tips you've seen posted elsewhere, etc.
Myself, last night I quickly attempted to open the editor (run doom3 with +editor for a setting to open it), but it opens in whatever my Doom3 resolution is, and I don't have a mouse pointer :( Makes it difficult to map.
I'm sure issue will be solved through some settings, and this is the perfect place for them, so we can all learn the new little tricks together.
Thanks to AceC at #ddom3world and RaP7oR in #tf for the following:
To have the editor run in a windowed mode (if your game isn't -- and who would want that?), and make it more accessible to run doomedit with say, IRC, add have the following in the properties window for a seperate doom3 shortcut (in the "Target:" box)
"C:\Program Files\Doom 3\Doom3.exe" +editor +seta com_allowConsole "1" +seta r_fullscreen "0"
Works for me.
The one major thing to note is the difference in compiling your maps compared to the 'Quake way'
D3 does vis(afaik)/lighting on the fly, so you just have to do a bsp compile. This can be done in game if you want to quickly test your map (how cool :) by typing;
Then the normal map [mapname] to load the map (or devmap [mapname] for loading with cheats enabled)
You will also instantly notice that an unlit map loads full black rather than full bright, so you'll either have to use the flashlight or (more usefully) stick a large light in to be able to see what's going on.
Oh, and pressing F2 in DoomEDIT will drop you straight back into the game, which is nice.
(And as an addition to what biff said, you'll probably want to add +r_fullscreen 1 to your normal D3 shortcut. You don't actually have to use seta in the command line anymore, just note the + rather than the - suffix)
Bah. Stupid quote tag (or foolish use of it anyway :)
Let Me Dump Some Of What I Know Already
Some of you may know this also but to get our knowledge base started:
Lights are now brushes.
Because of how very important it is to keep track of how light volumes overlap (because each light means at least 3 passes on every surface it shines on or something insane like that) lights all have definite bounds. All are rectilinear, or pyramidal.
For a rectilinear light, that's your basic area light. The pyramid is basically a cone but since it's projecting a square image it's a pyramid, thus being a spotlight.
The actual size of a light is determined by two things - the origin and the bounds. The origin is the usual diamondy light thing, and you can define three radii for X, Y, and Z. The volume is always centered on the light entity itself, and the light will fade from the center to the edge of the volume.
You can, however, make the engine fake that the light is originating from somewhere else. The pool of illumination you might want right by the floor to mimic light from up above, but that would mean the shadows would have to be cast from that direction. In the light editor you can check a box and move the light's perceived origin away from the diamond (it becomes a pink square) wherever you like. Note that if you move it into a brush the light goes dark because the whole room is now in shadow.
Note also, that to actually illuminate walls and floor, the light volume has to extend past the walls. Since the light's intensity at the edge of the volume is zero, if a light volume is the size of the box it's in then someone standing next to it will be lit nice and brightly on his face, but his feet will extend into darkness and no walls will be lit.
This means that your light volume might extend into other rooms. I presume Carmack was intelligent enough to cull lighting based either on vis or on shadowing, so there probably isn't any worry about a light from a room next door slowing down rendering in the one you're in despite not doing anything. I have not, however, tested this.
Light volumes also split the faces of the world where they intersect. Poly counts in this game are basically "nothing you need to worry about," but it never hurts to try and keep your lights close to the grid and not overlap them in terribly funny ways. So, of course, the default light radius is nowhere near the grid at a rather stupid 300x300x300, ensuring you have to change every light.
Lights are also no longer just gradients. You can create an image for whatever light you like. The flashlight is a good example of that, but nearly every light in the game is like this as well. Even the default light has an image with a kind of squarish gradient in it. When you see the soft-edged shadow of a spinning fan, it's actually a projection of a shader with a rotating texture pass. Lights casting a chain-link pattern on a wall usually aren't shining through the chain link fence, they're just an image of a blob with an X pattern over it.
That can lead to some pretty cool shit. See: stained glass windows, film projectors, etc.
Much more from me later.
Forgot to add, if you create a light with a shader that's basically a full white image, you'll create a box of fullbrightness cast from a central point, that doesn't fade towards the edges. Fade is determined by the shader image itself. If you create a spotlight, and the shader assigned is a black image with a filled white circle, you'll have a spotlight with no penumbra.
Area lights are by default projected from above. So, if you have that white circle light on an area light that intersects with walls, you'll have a circle on the floor but rectangles on the walls where the circle intersects them. See what I mean? AFAIK the only way to rotate the projection of an area light is to rotate the entity itself, but that makes it hard to work with because then you don't know what X is Y to what Z in what direction who what X whatever.
Where x is some number, 5 is 1024x768, 4 is 800x600, you should get the idea.
Scampie - when I started mine up, I had no mouse pointer, when I added +r_mode 5 to the short cut, all was good.
My DooMed shortcut looks like this
"G:\Doom 3\Doom3.exe" +editor +r_mode 5 +r_fullscreen 0
I Lurned This Tonight:
Materiallist.txt is not necessary.
To start the editor in the basedir of a mod, start doom3 itself with "+set fs_game whatever", and the editor will work out of the mod folder and fall back on /base/ as usual.
Scampie, here's the MEL for the light arrangement. To the unintiated, I'm doing my normal maps in Maya, and have this bit of code to slap in the correct arrangement of lights to create the RGB contour.
// Make the default lambert white so I don't have to fuck with anything
setAttr "lambert1.color" -type double3 1 1 1 ;
setAttr "lambert1.diffuse" 1;
// Create the five directionals, and position them
defaultDirectionalLight(-0.5, 0,1,0, "0", 0,0,0);
rotate -r -os 0 180 0;
move -rpr -z -12;
defaultDirectionalLight(0.5, 0,1,0, "0", 0,0,0);
move -rpr -z 12;
defaultDirectionalLight(-0.5, 1,0,0, "0", 0,0,0);
rotate -r -os 0 -90 0;
move -rpr -x -12;
defaultDirectionalLight(0.5, 1,0,0, "0", 0,0,0);
rotate -r -os 0 90 0;
move -rpr -x 12;
defaultDirectionalLight(0.5, 0,0,1, "0", 0,0,0);
rotate -r -os -90 0 0;
move -rpr -y 12;
// Create the ambient light that compensates for shadow lights
defaultAmbientLight(0.5, 0, 1,1,1, "0", 0,0,0, "1");
move -rpr -y -12;
// Orthographic camera looking down at this beautiful arrangement
camera -centerOfInterest 5 -filmFit Fill -orthographic 1 -orthographicWidth 16; objectMoveCommand; cameraMakeNode 1 "";
rotate -r -os -90 0 0 ;
move -r 0 12 0 ;
setAttr -lock true "orthoCamera.tx";
setAttr -lock true "orthoCamera.ty";
setAttr -lock true "orthoCamera.tz";
setAttr -lock true "orthoCamera.orthographicWidth";
// Layerize it
select -r greenDark greenLight redDark redLight blueLight ambientLight orthoCamera ;
createDisplayLayer -name "utilities" -number 1 -nr;
The orthographic camera it creates will face onto an area 16 maya world units on a side. Model to that scale (use the grid!), being sure to remember which direction is up on your surface. The bright red light should come from the right, and the bright green from below.
Render at whatever native size you want - I do 512x512 - and it will frame perfectly. RENDER AT INTERMEDIATE QUALITY. Production quality will anti-alias a black border into the image along all the edges, which you don't want. You're better off rendering at a higher res than you'll eventually use, and scaling the image down in Photoshop.
You're really all over this stuff.
I'm probably not even going to run the editor until I finish the game. I just got it by the way.
Thanks For The Info Lun
You the man. I'll be getting into some editing late this weekend I suspect.
Specially with the light info -- I had figured out the directional thing with the lights from playing with the id maps, but you've saved a great deal of time with notes =D
This all sounds slightly more complicated than Worldcraft. :)
Yeah It Does!
Something tells me there wont be a huge number of mappers for D3. I suspect a rather large learning curve with this new engine.
While this may _sound_ bad I dont think it will be. I just means that what mappers we do get will be a bit smarter than the average bear, and will likely mean better maps. So... if any of you big-brains need a play tester ;)
Intelligence is not the determining factor in learning to map for a game; it helps but it's not the most important thing.
Determination is more important and unfortunately there are alot more determined people out there than there are intelligent people. So enjoy the first month or so of crappy Doom/Doom2/Quake remakes and box maps with 10 cacodemons, because people out there are determine to show you they can make a map for D3 :D
I'd Have To Disagree
I'd be more inclined to think that there will be a huge amount of mappers for Doom3. Consider the following:
- the editor is radiant; anyone who has mapped for any Quake 2 or Quake 3 engine game is pretty damn familiar with it, and there's tutorials available on the basics of the editor.
- Doom 3 engine looks so good that it will probably attract new mappers, or drag them away from other games.
- in some ways D3 editing is actually _easier_ than earlier games; there's less worries with compiling the levels (you just run the BSP, yeah?), you have real time lighting previews in the editor
, the bump mapping and all that business makes it easier than ever before to make a map look good, even if its just a simple box room (look at some of the Doom 3 maps!)
- the level of control you have (I assume, from looking at the levels) over moving geometry, lighting, etc is great, and will allow people to do things they've wanted to do before but weren't possible in older engines.
- You have the editor and all the media if you've installed the game, you don't even have to download it!
- They've included all the .map files in the game paks! That makes it pretty damn easy to figure out how things are done, and gives people the opportunity to use bits of the id levels in their maps if they so desire.
- Because the interest in Doom 3 mapping will be huge, there's already tutorials and stuff popping up, even easy to follow video tutorials (from what I'm told) for newbies! You can't get much better than that. They're available here btw, if it wasn't already posted: http://www.planetdoom.com/leveled/videotuts/
I'm glad you guys feel the need to debate if there will or will not be a doom3 map community, but this is a editing tips and tricks thread for those who would like to start working toward one, so go discuss elsewhere.
Today's trick/tip? "J". This magical key opens the light editing window. You wouldn't believe how much of the time I spent last night just starting with the editor was wasted trying to figure out why the fuck I couldn't change the brightness. Lunaran's explination of the game's lighting makes more sense after seeing it in action in the editor.
Just To Piss Scampie Off By Continuing The Discussion....
It seems very easy to make good looking doom3 maps as long as you stick with the id content. If you want to make your own textures, models, scripted machinery, , gui scipts though it will of course require a lot of work.
Mapping Tip #1
If you want to make your own textures, models, scripted machinery, , gui scipts though it will of course require a lot of work.
The greater part of success comes from doing what others are not willing to do.
I Always Thought
the greater part of success was lots of beer and women?
It's a part of the success as well, but not in mapping..
I was curious to see what type of methods you all are using to caulk your levels for performance. I understand now, thanks to non/grind that it speeds up the bsp compile dramatically, and provides better performance in game as it does not draw any texture on its faces. The question I have tho is exactly how you guys go about using this caulk texture. To you all build the rooms and halls in the caulk then go back and texture just the visible faces? Or, like I have been doing do you create your work then just select all the outside faces and apply the caulk that way. The way I've been doing it however probably isn't the most effect as I've skipped over the brushces with metered angles, or brushes that come up against one another. I've also heard people just creating the room with the regular textures, then remember what textures they used, selecting everything inside a large brush, then auto caulking. Then of course they go back and retexture the visable faces. Any comments, suggestions?
I was reading elsewhere that the kind of obsessive caulking of non-visible faces people (including me) use in Q3 engine maps may actually be a bad thing in Doom 3. Apparently the stencil shadows are cast from faces whose where the normal faces away from the light rather than towards it - so there is potential for caulking non-visible faces to actually cause the shadowing to fuck up.
Haven't tried this myself yet though so this may be entirely untrue of course!
Going One Further Shallow
from what I've read of various tests, there's no reason to caulk everything anymore anyway since the game is really good in removing unseen faces as is. Plus, there aren't anymore structual/detail brushes anymore, so the use of caulk-hull techniques is out of the question.
who caulks the outer faces of structural hull brushes???
I've also wondered myself why people would caulk faces that are going to be culled anyways.
metlslime: people who don't relieze why they're doing something, but do it anyway.
From My Understanding
Appearantly the caulk-hull method has it's roots in Quake 3 engine games. Newer games such as Call of Duty rely on this technique as the current tools are not that efficient at removing faces from structual hull brushes. As a result many people have adapted to using the caulk for everything, then going back, retexturing and using massive ammounts of detail brushes.
In Doom3 the bsp compiler is efficient enough that the caulk-hull method is no longer needed. I believe some people in the Doom3world.org boards are having a hard time moving away from this technique. A few guys there have done some performance testing to back up this believe, and as Scampie linked a fairly knowledgable sounding guy also said caulk-hull is no longer needed.
Not That Any Of Us Need It...
But I thought I'd post a link to the little tutorial I just wrote up regarding geometry.
I Needed It.
Thanks scampie nice work :D I can never get my head around curves tho, would you do a wall curve the same method and how do you apply a texture to just the curved side of wall and caulk to the back?
Just taken a look around, followed some tuts and I didnt know it was that easy :)
whoa! what they say is true! mitering IS a thing of the past with d3's bsp process!
I must say, I am impressed.
um... by mitering, i assume you're talking about the way the brushes meet at 45 degrees?
how would that affect the lighting like you mention in your tutorial?
Nice Test Scamp
Thanks for pointin that out. I'll probably still miter like normal tho, I for some reason believe it keeps my map cleaner... what that means I'm not sure. I just feel it's tider with stuff mitered, not everything mind you.
I'll try to be more vague next post.
er? i never said it helped with lighting... never even mention lights.
but in Quake engines, had I made the example on the left, it'd have almost twice the polygons as compared to the section on the right, due to how they meet end to end instead of side to end.
To Best Show What I Mean...
here's the same test done in q3. show is taken the opposite way to show how it splits the wall bad too, so the mitre section is on the left now.
Uhm, That Is A Debatable Point,
but I would not be suprised if Scampie knocked this one clean out of the park.
I'll probably keep mitering out of sheer habit, and also because it makes the map look cleaner in-editor and helps me to see what's what at a glance, but it's nice that you don't have to be really anal about it and sweat performance anymore...
Headthump: I shouldn't even dignify a Half-Life mapper's claims with a response, but if you insist.
His argument is based on tests that don't have anything to do with real life mapping. In his first, he shows a light inserted within a 'pole', and somehow claims this proves that the bsp splitter is god's gift to render speeds. Without showing the tris, I see little reason to believe his argument. Here's the same piece, done in q3, on the bottom showing an unmitred peice, the top mitred.
If he's in fact not lying about there being no cut there, then there's more to the story than we're seeing. Possibly a decal? I know they exist in HL, but don't know how common they are in level design.
His second piece of 'evidence' just shows an example of the splitter doing it's job correctly and how we'd all expect it to work. A real world example, like in my first Q3 mitre comparision ( http://scampie.spawnpoint.org/d3/q3_mitre_compare.jpg
), shows the compiler just doesn't how how to effeciently deal with all the vertices of the various faces coming together and has to split things up. By mitering, and making more vertices meet at common places, less splits occur and thus less polygons are created.
Mitred brushes making the map cleaner is a personal call, I find in my mapping where I'm very concerned with overall design, it's much easier to see things. As for his final point, plane counts are a Half-Life compiler specific concern, and may well be true for all I know.
That's all I have for now.
Left Out Part...
His second piece of 'evidence' just shows an example of the splitter doing it's job correctly and how we'd all expect it to work.
Compilers do know enough to combine all brushes they lay flat as he's showing, and will merge all the faces that have the same surface properties.
thanks for that, scampie.
i don't know why i had it in mind that mitering affected light... O_o
i'll need to keep that in my for future maps. :)
The Penis Mitre
Nice work, Scampie. I'll have to remember that.
Very Useful Info Scampie
Mind you, I miter instinctively in Q1 and will no doubt continue to do so in Doom3 (if I ever get around to mapping for it).
I always thought the whole bsp/csg way of making levels would be phased out with the Doom3 engine, but after seeing those pics of how Doom3 "automatically" miters brushes, it looks as though the Carmack is perfecting it.
I shouldn't even dignify a Half-Life mapper's claims with a response, but if you insist.
I wasnt sure it I should have posted that link, but I'm glad I did. I've used both methods in the past, and mitering does look cleaner; esp. on the x/y plane where I organize my layouts anyway.
and i've seen so many threads on Doom 3 forums by people claiming the Doom 3 engine is "inferior". Inferior to what, Half-Life? Doom 3 may not be perfect, but the engine IS technically impressive. Carmack isn't some 15 year old who makes counter-strike mods, even if he looks like one.
I've started futzing with the GUI scripts, following the tutorials on d3world mainly. As soon as I started, I made a beeline (lol!) in my tests to see if you could apply normal-mapped shaders to a GUI, my goal being to create a switch panel or a keypad that reacted to light the same as other textures, and thus actually looked functional and real and not like a happy shiny hi-tech LCD screen.
Sadly, putting a material shader in a GUI object doesn't work - Apparently to Carmack it wasn't conceivable that you could possibly create an environment in which happy shiny LCD screens would be advanced and out of place - and thus begins the slow process of my starting to hate all the shortcomings this engine will no doubt limit me with.
If I hack something up to fake it I'll post the process but I doubt it will be elegant, pretty, or even satisfactory.
Send him an e-mail, he just might care and add it to a patch.
well, there's a secret in the game which seems to be what you're looking for... when the crosshair goes over it, it still beeps, but the mouse crosshair isn't displayed. it looks like a normal block texture... you can probably not make it beep too...
i don't know if this is exactly what you're talking about. i'm still trying to figure out how to make most of the funky moving stuff and haven't even looked at the GUI things...
That's kind of the hack I was thinking of. You can make a GUI that's just one layer with an alpha of 0 so it's essentially not there, but still responds to mouseovers and such.
I haven't even tried most of the funky moving stuff, I'm still revamping the PDA. :)
Lun, just make a new dm map. We don't need another dune mod fiasco.
Deathmatch Or Glory, Lunaran
Deathmatch or glory.
its just another story.
Don't talk like that Headthump, he may start thinking about Pissboat or Quake4 and become suicidal.
I wouldn't want that on my hands; normally, I just drive people to drinking.
Tips From Kiltron
I love innapropriate ports.
Automated map porter...Kinda cool still.
Is It Just Me
Or is the D3R vertex edit mode fundamentally broken? Splitting faces it shouldn't, crashing after snap-to-grid, horribly deforming perfectly valid brushes...
I Think The Vertex-edit Is Kinda Wonky Too...
And I don't know how to snap vertices to the grid if they're not on it already...Is there a quick and easy way to do this?
Also, I don't know how I managed it, but I had D3 applying two different diffuse textures to one face. Does anyone know how I could've possibly done that, and how to fix it or not do it again in the future?
BTW, they really should fix the patch editing...I can't see patches I've created in the camera view unless I restart the editor.
Don't use vertex edit for anything but patches. For brushes, 3D clipper is your friend. Seriously :I
Try CTRL+G and see if that will snap the verts to the grid. You may have to select the vert first, not sure (that's if it works at all, it works in GtkR, that's all I know).
That's what I was lookin for...I'm usin verts for patches, and when you create patches, sometimes the control points in the middle don't fall on gridpoints. Ctrl-G snaps points to grid, it appears to do all verts on the selected object.
Now if only I could figure out how I applied 2 materials to the same patch :-\
alphamaps -- like you would do with Quake Arena terrain (see the manual on qeradiant, I don't believe I have seen it used for non terrain but Paul Jaquays says there is no reason it can't be used that way).
Also, I don't know if the method carries over to Doom3; those martian landscapes were certainly done in a high end modeler like Maya.
Alpha Maps Are Cool
But that's not the problem I have...let me find a place to stick the screenshots, and I'll show you: I have 2 textures visible on the same surface. I want to know how I did that, and how to get rid of it...Or at least not do it again in the future.
Sorry, I Can't Help Much
I'm still a lowly Quake SP mapper though I am using Q3 bsp format on my latest stuff. I'm experimenting with alpha maps (for the first time!) in hopes of making my rocks prettier.
Glass Slow In Windowed Mode?
Am I the only one with extremely slow glass when editing/playing in windowed mode, or am I doing something wrong?
It's really fucking slow for me. Explosions and heat distortion too. r_skipPostProcess 0 required. I'm running an ATI Radeon 9600Pro with the latest Catalysts.
r_skipPostProcess 1, of course.
I Am In Hell
After familiarizing myself quite well with GTKRadiant in preparation for Doom3 editing, I'm quite disappointed to see that D3Radiant is nothing like it.
More than half of the textures don't load, texture alignment is a bitch, so on and so forth. Bleh. You'll find me trudging through the D3World forums for the next month while I try and crank out blitztest.map.
(PS this is a not so subtle cry for help. Please. I need tuts.)
"Alphamaps" In D3
Sort of. The blending is done by using vertex painted models.
Put vertexcolour in a material stage, and that stage's RGB data will be multiplied by the vertex colour. Black vertex = black texture, white vertex = normal texture. Add another stage using inversevertexcolour instead, and you can blend between the two stages by changing the vertex colour from black to white (or shades of grey). This is nice because it's very flexible, but you do need a modelling app.
Take a look at rock.mtr to see how it works in practice.
To fix broken textures, get this:
Bleh, I was going to write lots of stuff here and then I figured most of is was stupid, so fuck you hitler.
Just use GtK 1.5. It's a lot better.
gtkr d3 support was ass?
Yes, GtkR D3 support = ass.
GtkR 1.5 = ass.
GtkR 1.5 with D3 support = DOUBLE ASS.
I like 1.5 a lot better than d3r. It's a lot easier to use imo. D3r is so hard to get a knack for, but I picked 1.5 up in like 30 minutes. Besides, it's still in beta.
d3r is full off pantaloon bugs...
D3Edit is GOLD. Solid gold I tell you. There's only two things annoying me there which is a record of some sort.. 3D clipping is broken (try it, funky) and texture streching on rotated textures provides hours of puzzlement. Strech first, then rotate!
I like the in-editor rendering (and the ability to switch into D3 for entity testing) too much to switch to 1.5 which doesn't do all the stuff like particles and GUIs.
Blitz, don't worry about missing textures. There's a lot of obsolete material files. Just get the fix if all the black boxes in texture view bother you. I personaly don't care.
And since this is a editing tips thread.. I assume everyone knows this already, but just splitting faces at light boundaries isn't enough. They get merged back together in the compile. You can stop this by mirroring the texture on some axis, or giving it 1 unit (or less, haven't tried) offset. In some cases you can't even notice it in the game unless you don't know what to look for. Brings up framerates nicely.
Another thing.. when running D3 in a window, never ever type 'QUIT' in the console. Instead just pull console down and shift focus back to the editor. I've noticed this almost completely eliminates crashes related to reloading the map in D3 after compile.
Don't bother carefully placing and rotating the moveables, ragdolls and whatnot. Just rougly place them, launch game, show ragdolls who's the boss with g_dragEntity 1, push & shoot the moveables around and then do saveMoveables and saveRagdolls. Loading up the map again in editor shows that stuff is nicely disorganised now.
Objects and Decals texture folders are totally worth of extreme abuse. Loads of good stuff for building all the cool small things. Base_wall also has some stuff that should belong to either of those. Func_FX stuff is also something worth checking out. The syntax is quite simple and you can do nice combined effects with it (light, sound and particles in the same entity).
Don't use lights with shadows turned on, unless it makes the area look cool, monsters or other objects need to cast shadow there or you have movers that should cast shadows. In most cases, lights player can't reach can have their shadows turned off, which helps framerates. Fog is just a light with all options turned off and fog texture selected. Thickness can be controlled with shaderParm3, value being the distance in units where it turns completely opaque. Darker (really dark) colors look generally better than bright.
Use speakers liberally but with moderation. If you think some detail in map could emit a sound, add speaker to it. To avoid oversaturation, use short s_maxDistance and low volumes when dealing with directional sounds. Sounds with s_omni set are great for adding general ambience sounds for areas, don't overuse these or the sound will get murky. IE. 8 s_omnis in a small room isn't that great idea. Since there's no music, you'll want 100% ambient sound coverage for the map. Add sounds as you go, it inspires mapping a lot.
And if you add that goddamn mars buggy model to your map, go play CS.
A Big Issue
I hate the camera in D3Radiant. It's so hard to point at excatly what you wantt, which I think is the main draw of having a 3D view. Anyway my hope is that GTKRadiant gets better support, someone makes a new editor, or D3Radiant gets patched/optimized.
The camera is plenty accurate enough. And if you really want to finetune it, press mouse 2 in 3d viewport and move mouse around. I find it quite speedy enough just with keyboard commands.
speaking of sounds, Ive been having issues getting them to work.
Most cases I want untriggered area sounds with low volume. but so far I've managed silence... :(
You have s_looping 1 set? Do you have the entire path in s_shader, including the extension? (.ogg in most cases)
And CTRL+MOUSE2 in the 2D view jumps the camera to the clicked point
That should of course be mouse3, not mouse2.
And just clicking mouse3 on it's own in the 2d port faces the camera at the point you clicked
shift+rclick in z-checker sets lower bounds, ctrl+rclick in z-checker sets upper bounds, ctrl+shift+rclick in z-checker enables/disables vertical bounds, so radiant only draws brushes and objects that appear between the bounds. Useful if you're working on a level that's somewhat vertical.
Custom Entity Names
adding +seta radiant_nameprefix <yourname> to your doomedit shortcut is quite handy if you are working with someone on a map, for example if you make a light, it will be light_yourname, atleast that way you know who put what where, hope that helps somehow :)
good to know zombie, cheers
actually that is a very tasty feature for larger projects indeed.
But I did not see it: When I click my shortcut my desktop gets fullbright. You know what I mean - Everything becomes SUPER bright, like maximum brightness. Why is this?
My shortcut looks like this:
"C:\games\Doom 3\Doom3.exe" +seta com_allowConsole "1" +seta r_fullscreen "0" +editor +r_mode 5
I couldn't find a shortcut or answer to why this happens, even browsing Doom3World.org.
probably the ing-game gamma -- hardware gamma correction occurs on the entire screen, rather than just on a single window.
probably the ing-game gamma -- hardware gamma correction occurs on the entire screen, rather than just on a single window.
Yes, which is annoying as hell when DOOMEdit crashes, leaving my desktop gamma the same as what I was using in DOOMEdit (which I set as super-bright so that I can actually see shit in real-time lighting mode).
Save Your Retinal Integrity - Get QuickGamma
From shaderlab.com. It puts a nice simple gamma control in your tray, making it fairly easy to use DoomEdit at the same time as other things without going blind.
which is available on the fitzquake page -- it's command-line activated, which might suit your needs better (or worse.)
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.