Search the Community

wow, awesome!! makes me wanna model again

Technically you could do this now. Other than pauldrons, I'm not sure what would look good though. Breastplates or gloves would need to be able to move and bend with the model. Helmets would already be covered by head swapping...I can't think of any other armour pieces that would work. Did TDS do this with any armour other than pauldrons?

We also have a contributor option where you make something (whatever it is you're good at) and contribute it. This is a nice option if you don't have much free time as well, since it might take you 6 months to model a wagon wheel or program some feature, but in the end we're still glad that you gave us that wagon wheel or feature (okay bad example, we already have a wagon wheel).

It's probably not fair to compare the two, since with DoomEdit you have the whole game loaded as well. Nevertheless DarkRadiant having acceptable memory usage is a good start. I agree, this is much easier to use. Glad you like it. Yep, this should improve with the Media Browser, which will allow you to load any individual texture or group of textures into the texture preview window. These won't take the form of buttons, but of Property Editors in the Entity Inspector. I.e. when you select the "model" or "skin" property, a widget will be displayed allowing you to browse these DoomEdit-style. Initially I was planning to do a separate light inspector, but decided to merge this functionality into the Entity Inspector. I might consider a dedicated dialog for lights if enough people request it, but it's not a priority at the moment. The usage information is parsed directly from the entity definitions, there won't be any way to expand on the information that the developers put into the DEF files.

Both. You can select a single brush, right click, "Create Entity", then select the desired entity and choose "Add", to turn the selected brush into an entity. Alternatively you can do that same but with no brush selected, and the entity will be created where you right-clicked. This is in fact the same behaviour as DoomEdit, it just adds an extra dialog between creating the brush and selecting the entity. This allows "Add model" and "Add light" to be given more prominence, as well as avoiding the problem associated with a huge and ever-expanding context menu.

I just did a little test and our current AI (builder guard model) does not fit through a 48x96 door. That is fairly inconvenient insofar as I'll have to resize all of my doors in all of my maps. I have always naively assumed that if I fit through it the AI will fit through it. No such luck. EDIT: The Builder Guard does fit through a 50x100 door, the Cityguard fits through it theoretically but gets stuck 50% of the time in practice.

Whew, that is great news. I was dreading even thinking about having to UV map everything twice, AND making them match. I guess it must use the low poly UV map for the coords? Yep, in fact here's how I made my little test case, for simplicity. I took my simple cube for the dice and exported it, ready for in game use. Then, I took the same file and added a bevel, subdivided a few times, and then smoothed a bunch. Didn't change anything else, and exported as dice_high.ase. So they must coincide. I'll try a new test with no high_poly UV map, but I still can't figure why D3 is giving me a blank. If it's useful info, the dice_d.tga file (presumably diffuse) that ORB is spitting out is the same as the D3 normalmap - a grey field. Could it be that Doom3 is being instructed to export the wrong map? I could give the high poly file, if anyone wants to try that with the material and low poly which are already on CVS (except for the extra instructions pasted above). Edit: Yay, it just worked in D3, too. I don't know why, the only thing I changed was generate a brand new high poly model and not provide a UV map at all. Maybe that was causing a problem somehow? Either way, success!! Thanks for the help guys.

Okay, I got it working with ORB. For whatever reason (probably depends on paths and materials more than I expected) it crashes loading local copies of the files, but seems to work with the darkmod-foldered items. Anyway, I generated a 2k poly normalmap in a few mins - which definitely tells me D3 isn't working, since it's done in 8 seconds, giving me a grey TGA. This leaves me with two lingering questions. 1. Why doesn't it work in D3 with renderbump? Is it just much more sensitive to everything being set up in one exact way, and ORB is that much more forgiving? What little facet am I missing? 2. I'm assuming UV maps must agree between low and high poly versions (how else could it work?) How on earth is this achieved? I did it with a simple cube as proof of concept, but most game models aren't cubes. High poly versions will be much harder (and I'd imagine sometimes impossible) to reproduce the low poly UV map exactly. Is there a way to export or transfer the low poly UV map into the high poly model for export and use? Or is that the wrong approach completely? Could it be that (dare I dream) these things take the high UV map, and map it onto the low UV map shape for the output image? Learning a lot in the past week. Head hurts.

There should be a door model included in the darkmod stuff that we're using as a default. 48 width is a must right now based on the AI bounding boxes, however.

I did some tests on this a while back. You don't even need to do a head swap, you can just to a face swap. WIth the elite city watch for example, all you see is his face anway, so all you need is a new face model that fits into his chainmal coif. Perfect job for facegen. Any of you guys can do it. Well, it would be better if you had some modeling skill so you could furthur alter the facegen face in lightwave to give it more charcater, and alter the shitty facegen texture in photoshop, agin, to give it more character.

I tried ORB, but for whatever reason, it crashes when even trying to open one of my Blender-exported ASEs. It can open the ASE from 3DS which comes with the package (of course), but not mine. So I'm giving Doom3 another try. Could any of you give me a sample material (or heck, even a low and high model and material) that I can look at and emulate? So far it's not working, and I don't really have any idea what I'm doing wrong - no example on modwiki, no example on iddevnet. Edit: I'm just not getting this. From id's mapobjects.mtr, the only type of hints I can find: renderbump -size 512 512 -trace 0.1 -aa 2 models/mapobjects/hell/torches/torso_local.tga models/mapobjects/hell/torches/torso_hi.lwo I emulate that with my assets, even though it makes no sense to me, and it of course doesn't work. Why is there a *_local line in there at all? I'm trying to generate the normalmap; why would I include a normalmap in the material definition? What the hell? Time wasted++.

I'll do the function for dynamic attachment as soon as I can (which needs to be done before we can refresh any, otherwise it's just done at spawn). However, there is another option for accurate attachment that could be done right now: If the modelers could just open up the AI and read off the coordinates with respect to certain joint coordinates, we would know exactly where to attach stuff. Apparently there is some difference in going from model units to doom units, but I would've thought this would be a known conversion by now?

I recommend using ORB (http://engineering.soclab.bth.se/tools/177.aspx) rather than Doom 3's renderbump. It is more interactive and does not require setting up MTR files to define the parameters. Otherwise, you have to have a renderbump global keyword in your low-poly model's material definition, giving the renderbump parameters and the path to the high-poly version.

You could try creating a collision model manually by adding a second, identical cube textured with common/collision (or whatever it is). I find it hard to believe that there is a grid resolution in the calculations, but there may be one in the automatic generation of collision models. Yes you can, but it rules out using stock textures, collision or shadow meshes and the like. Excellent, I'm glad something finally worked in your Blender setup.

Ugh, how stupid. Ah well, you've saved me some toil then. Good about the unweld script, and the notion that smoothing wouldn't be a problem so much for larger models (I have no perspective on much of this at this time). One last thing bothers me a bit about this model. It hovers by 1/4". This seems to suggest that Doom3's smallest collision resolution is one grid unit (seems reasonable). This obviously can be a problem when items are this tiny, and/or smaller than one grid unit. So I have the following choices: Make it smaller so it falls on the grid; then it's too small. Make it larger so it falls on the grid; then it's too big. Leave it as it is, and tolerate 1/4" of levitation. Edit: although, about the material, I assume you could name it something short, e.g., in this case, //base/dice Edit: great tip on the unweld script. Worked.

Fixed, and much better. Thanks guys. Hm, that smoothing thing is definitely a problem then; what if the model was 2000 faces instead of 6? Also, our arrows are ASE - ascottk, were you able to avoid this problem? I'm going to look into seeing if I can force Blender to make use of D3 material paths, because otherwise I see no way to texture LWOs as an alternative - after an ASE export, one must manually edit it (which ASEs allow, and LWOs don't) to make it use the right material. Any further advice/tips are always welcome.

It makes no difference whether it is smoothed in Blender - when the ASE is loaded into Doom 3 it will be smoothed automatically unless you unweld vertices to prevent this. This means in Blender you have to select each face, and press Y to "split" the face away from the mesh. To split a cube in this way you need to do this four times - top, bottom, left, right (and the last two will be split as a consequence). As a hint, when modelling in Blender make sure smoothing is turned ON for the whole model, this will then simulate Doom 3's rendering and allow you to see what you need to unweld and what you don't.

it's a problem i've also seen before. You get a nastykind of shadow/smoothing near the edges of you models right? Smoothing with whatever setting (hard or soft) on ASE models doesn't seem to work that well or has no effect at all, at least what i've experienced in Maya. You still get that global smoothing thing. That was one of the reasons i choose lightwave for final model format.

This sounds like a good idea for TDM. We'll just auction off an exciting opportunity to appear* in our game! *upon receipt of award, awardee must model, rig, animate, texture and export a low-poly version of self in setting-appropriate garb

It looks like vertex shading. Are you sure it wasn't smoothed in your 3d program? Or maybe you've converted it from another format and convertion changed the smoothing groups? Or maybe normal map is missing and doom engine smooths model by default? I'm not sure - just guessing.. But anyway - I was really shocked!

1. This is a modelling issue. We should use mitten hands. There are no "characters of importance", since this is a generic toolset that doesn't contain plot characters. There will always be multiple clones of every character we model for this toolset. 2. Whenever. It means the anims have to be re-exported though. I think the more important question is - when will the command line interface for adjusting AF attachments I came up with going to be implemented? Otherwise you'll be back to spending hours on one attachment 3. It doesn't mess up the anims but it means they'll have to be re-exported. How you're going to swap the heads in game is up to the coders. 4. This is a modelling issue. 5. Personally I don't think that takes priority over doing the animations we had to cut out (such as a female walk cycle). In Thief you're barely ever face to face with other AI. 6. This is a modelling issue. Regarding the modelling issues, I suggest re-posting them in the modelling board if you can. I can possibly provide some input (not much) but I'm running late right now.

Personally I prefer not using motion capturing for our models for a few reasons. For one, it's harder to really tweak and modify, so if it isn't exactly how we want it as it is we'll probably be spending quite a bit of time trying to do that anyway. Also, sometimes motion captured animations don't "flow" into premade ones as easily, at least in Thief the animations were more or less consistantly stiff, having a combination of totally lifelike movements and ones that are less so can look a bit odd. This is especially a problem when some parts of the model don't have motioncapturing, for example in the walking animation the hands are totally stiff, so those would end up needing to be animated anyway. And I'm not sure how easy it would be to apply motion capturing to the rigs we're using anyway without messing something up. I don't think it would be too big of a problem animating parts that we would be able to use motion capturing for. There really isn't that much that would be motion captured that would fit what we need, other than basic walk/run cycles.

Just to fill out the implications of that, that suggests the collision model, if it isn't varying by head height, and you want head bob, will have to be set at the highest head height setting. For as troublesome as jiggering into tight spaces was in the original series, at the same time it did open up more player freedom by covering slightly tighter spaces than could be done without this effect, when the current height of your head is the ultimate judge of how low you can go, and not a set boundary always below which your head bobs (possibly unintuitively). Don't get me wrong, the trade-off may be worth it in player convienence, my intuition is that it probably is, but I think it should be seen as something of a trade-off.

I'm pretty sure it won't. I seriously doubt the head-bob will be tied to the collision model.

The main reason it would be nice to keep the sword on, if it won't be problem to remove when we actually import the model into the game, is so that we can see precisely how the sword will be oriented when it's attached in the game instead of having to guess where the sword will be based on the rotation of the hand. Alternatively, if we could simply set up a dummy bone in Motionbuilder that functions as an indication of where the sword will be when it's attached in the game, that would also work. Otherwise it would be hard to tell exactly where the sword will be in each part of the animation, for example when it's being drawn from it's sheath you have to go through pretty much every frame and make sure that the sword doesn't go outside the sheath as it's being pulled (an issue I noticed with our current draw animation). In any case, it would be nice to know what it will take to remove the sword and have it attached in the game rather than having it be a part of the animation. I can work without it if need be, the animations can always be tweaked later if we need to change things like hand orientation.