Search the Community

It may be a closed beta, but he had posted the link on the polycount.com forums which are public, and did not restrict who could download it. I'm trying to find the links to the forum's topic, but I can't find his thread. It had some cool screenshots. EDIT: Found it http://boards.polycount.net/showflat.php?C...an=0&page=0 Some screens: Here's a quote from one of his posts:

Heya Orbweaver, Might have another hand for you. Dark Mod <darkmod_apply@hotmail.com> wrote: Hi parsonsbear, I received your email about wanting to help. What type of programming background do you have? Just need some details so I can create an application thread for you. If you're interested, there might be some programming for you to do on the main mod...but if Dark Radiant is your true interest, we can certainly use the help there as well. I can't find your username on our forums. Which forum are you registered on as parsonsbear? Thanks. N.H.

Actually it's pretty easy to get things to spin, it's just one line in the projectile def to give it a launch angular velocity. As for special mapper-placed tags for everthing to take cover behind, we usually try to avoid solutions that make the mapper place tags everywhere for things, when possible. If we did that for everything, the mapper would spend all their mapping time placing special-case objects. Also, the AI should be able to know that they can take cover by going around a corner if the player is on the other side, but it would get pretty tedious to tag every corner in the map.

I was wondering about the "rudimentary 'take cover' behaviour" will it be anything like the behaviour in fear? cause what they did in fear is giving the items in the 3dworld id-tags so that the AI knew what to do if there was any object in the neighbourhood to take cover with. This also reduced the need for raw CPU processing power. If you could implement something like that then you could focus on the animations of the characters instead of writing something like this behaviour completely anew. greetz p.s. i dont know anything from coding but webbased coding, so it is rude to asume it will be easy to implement into the dark mod and you probably have your priorities somewhere else p.s.s. the update is looking good

Perfectly ok with me, feel free to change the default settings in input.xml, mappers will always be able change it to something different. You mean if there is anything selected and the user hits Shift-P the patch gets created and the brush stays there? Should the selection really get deleted on patch creation? I wouldn't like this, so I would make this a configurable option (i.e. registry key value). Yes, I like the clipboard idea more than DoomEdit behaviour. If I was to implement D3Ed style texture copy, I would have made it an option, because I find it much less effective.

I just tried this out, and it works like a charm. I think we can simplify the modifiers a bit -- there is nothing else using MMB in the camera view AFAIK so we may as well use something easier to remember. I find MMB for copy, Ctrl-MMB for paste projected and Ctrl-Shift-MMB for paste natural to be quite comfortable, although you may have a better suggestion. One thing I think we should change is patch creation - currently this does not delete the selected brush which I find inconvenient and will probably confuse DoomEdit users. Also, I retract my suggestion that the control system should be inverted so the target patch copies its texture onto the currently-selected patch. The ability to copy a texture once and then rapidly deploy it onto numerous surfaces seems to be advantageous. However we must make sure that the undo support is impeccable in case a user targets the wrong patch -- which I think it is, based on cursory testing (i.e. I tried it once).

Can I load these map using console? (if yes - what are their names) Yesterday I spent short while on reading Doom Edit Forum and actually that's sad but true - AAS compiler ignores models. So I thought about making caves as prefabs - for each part I would make proper monsterclip brush, so mappers wouldn't have to build that all from scratch - only the transition parts (I mean entrance connecting with outside or some cellar rooms, etc...) or if they want to customize and make the cave more unique. That's a great idea. I just realized why guards in Dram's dinning room couldn't find the path to catch me while I was at the opposite side of the table - they kept running into that table. Such automatic monster clip, which would solve that problem with just one click would be really helpful. AFAIU there is also some texture monster_clip_full or something like that. The diffrence is that it also blocks sight. Or maybe it's called completely diffrent (sorry, I can't remember) but I know, that there is another one for blocking the AI sight - it would be great to make this kind of automatic brush as well... ------------- BTW: did anybody try to make monsterclip mesh for some models? (just like collision model). Maybe such mesh would be included in AAS compiling process....?

At least it's customisable, so the users can choose what mouse buttons and what modifiers they want to use. (Not quite like a pop-up menu, but I don't like those too much anyway...) I'll finish reorganising the brush.h header file, and then I will look into the upgradepaths / xml file handling. Once this is done, I would say this thing is ready for takeoff.

No, after the texture coordinates have been calculated, they are "baked" into the patch, there is no meta-information available à la "this patch was textured using brush and scale using face normal vector". However, as the originating brush face is saved in the clipboard, you can check out both results by just using different modifiers (Ctrl-Shift-MMB for projection, Ctrl-Shift-Alt-MMB for natural, by default). That depends on when we reach the next stable state between the feature implementations. Orbweaver is working on some inspectors at the moment, I don't know how much is still left to code. Perhaps there will be some christmas release?

I'm planning to add automatic monsterclip brush creation to the DarkRadiant model selector, but it is unlikely to be more complex than a simple bounding-box, making it useful only for statues, furniture and other ornamental meshes.

making caves with patches is not very efficient. It's better to model it in a 3d app. I usually start with a floor plan of the route and build the area's out of brush rooms which i export to obj. Then i would build the model on top of the brush area's. Kind of like how id software created their caves. anyway making cave prefabs sounds a bit difficult. Mappers are better off with the way i wrote above because you have more control over the way the area's are constructed. With prefabs i would think more of rocks and other objects you can place inside your cave.

Done . I wasn't able to commit this during the last weekend, because my DSL went down till today. Basically, it's now possible to seamlessly texture a brush/patch transition, such that the texture is preserved in scale, shift and rotation. So it looks like this (left is the patch with its control vertices, right is the untextured situation): One is now able to choose between two texture copy modes: 1) Projected and 2) Natural The result on the left is the projected texture copy (note the distortions on the patch). However, for coplanar patches and inverted end caps this works like a charm. The right image was done with the new command ("PasteTextureNatural") accessible via Ctrl-Alt-Shift-MMB. This virtually "flattens" out the patch and therefore allows undistorted texturing, as the 3D distance between two control vertices is taken to calculate the texture coordinates. The result is undistorted and of course seamless to the adjacent brush. I think this already works in DR. At least the above steps are all undoable as far as I know.

I can see that working for statues and gravestones and so on. Caves are trickier, depending on how they're constructed. If the entire cave is one big model with a hole in the middle of it, then you can't just create a monsterclip brush that encompasses it, or AI won't be able to pathfind through the cave at all. What you want to do is put separate monsterclip brushes around the walls and floor (and ceiling as well I guess, in case someone makes flying AIs later). If the cave walls, floors, and ceiling are actually separate models that the mapper must place together then it might work, but then the mapper has to spend time lining them up perfectly. The caves could be presented as prefabs, but if you're going to use prefabs you might as well put the monsterclip brushes in the prefabs themselves, which means you can go back to having the cave as one connected model. Edit: Is there anything preventing monsterclip brushes from being complex shapes? If not, DR could just copy the model's shape as a brush, apply monsterclip, and place it in the same location. This is essentially what Thief 3 did (unless you told it not to). I don't like the implications this would have for AAS complexity though; it was a problem in T3, and with Doom 3 having airborne AAS areas as well as just ground-based ones the problem could be much worse.

I wonder if it might be possible to do something in Dark Radiant to slightly automate this? When placing a model, have a 'monsterclip' checkbox that can be ticked off. If there is a tick in the box, DR would draw a monsterclip textured brush around...or inside the model. Similar to the ai navigation options in T3...just eliminates the need to have the author physically draw these for every model.

The problem is that AI don't include models in their obstacle-avoidance calculations, so they won't pathfind around them. That would be a problem for a stalgmite or pile of rocks in the middle of a cave, but I'm not sure how that affects the cave walls. I would suspect that AI wouldn't try to pathfind through a wall if there was nothing on the other side, but I don't know. You could test it pretty easily with a cube model though. From my (not very thorough) research into how D3 did it, it looked like they built traditional brush rooms, and then used models to camoflogue the walls and make them look less blocky.

There is actually a "textool" plugin, currently disabled, which supposedly provides UV-like texture editing capabilities (where you view the brush face as a polygon and drag its points over the texture background). It would be worth seeing if I can get this working and possibly integrate it with the Surface Inspector in some way.

IMHO, texturing is one of D3ed's biggest weaknesses, and if DarkRadiant had good texturing capabilities that'd probably be enough to get me to (mostly) stop using D3ed... There's a wishlist of things I've wanted... 1. The ability to set the "origin" of transformations. In D3ed, when you scale or rotate, I think it's always around the world origin. This is very inconvenient. It'd be nice if when trying to rotate a texture to fit a wood beam, I could set the origin at a corner vertex (or some other spot) and just rotate it until it fit, instead of having to iteratively rotate it a little, then shift it to see if it lines up with the beam, then rotate it some more, then shift some more, ad infinitum. Similarly, for scaling textures, it'd be nice if I could put the origin at a corner vertex, and then scale the texture until its size matches the beam. (instead of scaling, then shifting to see if the size matches, then scaling again, etc) Preferably, I'd like to be able to set the origin at any location. 2. The ability to undo transformations. At least I should be able to undo them to the state that existed before I opened up the texture window or before copying a texture's orientation. In D3ed, sometimes I'll work for a half-hour, iteratively rotating, scaling and shifting a texture until it matches a brush... then I'll accidentally middle click another brush or some such, and lose all that work. 3. The ability to project a brush-face's texture onto another brush-face that's not co-planar to it. (D3ed lacks this as far as I can tell)

greebo - if you need some grave models for your map, you might want to use one of the models I have made recently. They should be on CVS by the end of this year. Take a look at this thread to see what's in the set so far: http://forums.thedarkmod.com/index.php?s=&am...ost&p=91243

I realise it's a little different, but I'm naively assuming the code base would be a similar area, but would it be possible to develop any kind of analogue control over texture placement? Have a certain brush selected and, with a key held down, use the mouse to position the texture? I know we have specific placement controls in the texture editor but I can think of several intances where this analogue type of control would be beneficial.

Perfect. If it is not too hard, it would probably be worth switching around the controls so that your middle-click operation grabs the clicked texture and puts it on the selected brush, rather than copying the selected brush's texture and pasting it on the clicked brush. This is more consistent with DoomEdit and might avoid inadvertently changing the texture on the wrong brush.

Some good news: This is the original situation in my testmap: This is after four mouseclicks (Ctrl-Alt-MMB on the source brush, 3x Ctrl-Shift-MMB on the other three): So I guess this feature is as good as implemented . (I will have to do some clean-up before I can commit this.) It took us (both angua and me) four to five hours to figure out how the world coordinates are transformed into texture space. The actual implementation took me approx. 20 minutes . We also came up with some more ideas that should make the texturing of bevel patches really easy, so expect more to come!

There is no reason why there should be any limit at all on the physical size of the map (unless you exceed the numeric resolution by having a brush at 2^80 units or something ridiculous); it is the complexity that is important -- polycount, number and size of textures, entity counts etc.

I really have no idea, this is most probably the result of some serious ego trip... The deeper I'm digging into the brush code, the more I want to reorganise it. What the heck is the point in maintaining a file with fricking 4200 lines (see brush.h)? Regarding that interface you mentioned: perhaps I will really do this, but I think I will need some assistance when that time comes, especially when it comes to implementation details (I'm still green regarding C++ design). However, for now I'll try to get the feature completed without doing a whole rewrite, let's see how far I can get...

It might be worth considering whether you want to define proper interfaces for brushes/patches, for example IBrush and IPatch which go in their respective include files, which could (amongst other things) return this sort of information. At some stage I am planning to rewrite the import/export code such that the mapdoom3 plugin walks the scenegraph itself and reads/writes brush and patch data using such interfaces, rather than having brushes/patches export themselves into tokens (which breaks separation between the primitive data and the map text format).

I have made some progress at last. After a short intermezzo with the brush_primit files, I added a method to the Patch class, which gets called on the PasteTexture command. In this method I read the scale of the texture definition and apply this very scale to the brush. Before my change it was only possible to copy the shader name to the patch; right now the scale is copied over as well. For the next step, I will have to figure out how to retrieve the shift values / texture coordinates from the brush face and apply it to the patch accordingly, which will be a little tough, I'm afraid, but it should be feasible with some projection operations.