Search the Community

Yeah, I'm talking about all models that have a specific direction: statues, cabinets, bookshelves, etc. Doom 3 assumes that models face east (0 degrees) by default, so if modelers could make such models face east, it would be more convenient for mappers who like to use the 8 directional buttons. For example, try putting models/darkmod/props/furniture/commode.lwo into a map as a func_static. If you press the 270 (south) button, it instead faces west. In order to get it to face the direction you want, you either have to spend some time thinking about which button to press, or try them all. It's inconvenient. It would be easier for mappers if they could just press the south button and the model would face south.

Another update; Ive started working again so I havent had a lot of time but im still chipping away at it, I dug up an old skull model I made a couple of years ago and made a low poly version of it I know its not very 'castle' but I think It would look good on a round coulumn, it can be used by mappers to place anywhere its stone so it blends in nicely with stone, ive also been working on some Ivy, its nice to see some colour on the stone The skybox was made in max using the projection modifior, I took the photos myself from a lookout in the country side of Victoria joined them all together and removed all signs of modern civilisation, it reminds me a bit of the background of 'tower af babel be peiter brueghel http://www.postmodern.com/~fi/pattimisc/ba...by_brueghel.jpg

I think this makes working in DoomEd a bit more elegant. This allows you to minimize the 'Inspectors' window in DoomED, it increases the size of the model/particle effect viewer and removes the annoying save error. Apply this patch to an 'untouched' up to date 1.3 doom3.exe. If you have applied sparhawks save error fix previously, you will need to restore your doom3.exe before applying this patch as the 'error fix' is included. Doom3ED_Patcher.exe

I didn't want to make an entirely new thread for this, and I am by no means associated with NewEgg or any other business for that matter, but (while we're on the topic of computer hardware) I just felt it would almost be greedy of me not to show my fellow forum members this amazing deal on NewEgg I stumbled upon (well, it was more or less on the front page). I know most here are cheap when it comes to buying new computer parts (as I am, especially with graphics cards), so when I saw the following offer I was siked. They have a Geforce 7600GT 256MB 128 bit GDDR3 PCI-E card for $80 with a rebate (down from $143). I've had the same card (actually, it's the same model, but it's a different brand--specifically mine is XFX) since early summer, and it runs today's latest games quite well (Any Source based games, RoboBlitz (Unreal Engine 3), Quake 4, Battlefield 2, ... ; I've run them all many times on this machine, even though I don't own many of them). I'm not sure how well this card will stand against games like Unreal Tournament 2007 (it will probably need to be run in low quality mode) in the Fall of 2007, but there aren't too many PC games I can think of coming out with such rediculous graphical detail. I know the card won't be capable of running Crysis (but whose computer will be able to run that anyways?), though. Just figured I'd let you guys know. The rebate only lasts until the end of this month, so if you're at all interested, you have a limited time frame. Also, note that given the fact that this card is a different brand than mine, performance may be different than what I experience. You may want to do further research (or perhaps there are even better deals available at this time...I'm not really sure. I just figured it couldn't hurt showing you all this). Oh, and here is the link to the card (almost forgot to post it...): http://www.newegg.com/Product/Product.asp?...N82E16814143049 (Did I just waste 5 minutes of my time to write all of this?)

I'm not sure how you could show the spinning in a still shot. If it didn't spin, I would assume we would see the model straight upright in the world, but I guess it might shoot at the player like an arrow. So the question is valid enough, does the bottle spin yet? (if it doesn't, surely they will make it so later on)

Man, I wish I could do drawings like this I really love the big statue in that concept, I think this will be one of the next models I will have a go at (if none of our modelers jumps at this one first). I already made a similar statue for the first "release" (with open hands holding a cup), but it's not very well textured, and it's not that expressive as this one. The actual entrance could be a little smaller, like in the first concept you posted, and (as already mentioned in an earlier post) a short sort of "canyon" really would add to the tension. Could you combine these ideas in another concept drawing? As for items and objects: angua already asked me to ask you for a concept of a statue, but I think you're nearly there with this concept. Perhaps you could draw a larger view of just this large statue (this would also facilitate the modeling task even more). A gargoyle would also be really cool, but even harder to model, I'm afraid. Anyway, we really appreciate your concepts, so thanks for that and keep up the good work!

Just saw that the throwing animation was on the front page from the picture. Cool, glad it worked out The other animations are mostly done, I want to try tweaking them a bit since the feet still don't match up very well. I'll admit I've been a bit lazy with these, freehand animating gives me a headache after a while I'll try to get them up later this week though (at least the 3 non-walking ones and the updated zombie animation), hopefully thursday or friday. The other two walking animations I'm not sure about, I'm thinking of just doing a bit of a rush job on them so that we can have it in the game and then when/if we get the character controls thing working I can update them so they look more natural. One thing though, how did we manage to convert the throwing animation onto the new models? Did we have a .def that took care of reasigning the bones and such? If so, maybe we can use the old model which is set up for Motionbuilder and then simply run the def file on them to convert them to the new rig. Might be faster at this point.

Try derTon's model viewer found on Doom 3 World.

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....?

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.

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.

so far the typical model has been 19.99US for around 4-6 hours of content. so 8-12 hours is 40 and 12 - 16 hours is $60.00. My numbers may be off here. I remember reading something about the hl2 episodes and I remember thinking that for 60$ you were getting around half of what half life 1 was. While some games are around 12 hours of playtime, many far exceed that. I think almost all episodic content will end up costing you much more in the long run. Plus, so far at least, it seems episodic content is synonymous with steam or some sort of online product activation.

I think I can create a new version that allows it to be seen from above and below, if the sides are a single color. I'm pretty sure animated materials have almost no effect on performance, especially given given the small icon sizes. Icons that rely on scripting to be animated (such as a compass, even with a model) might have a very slight impact, but the compass is pretty much a worst-case scenario (while selected, its script has to be run every frame), and for me the compass has no noticeable effect on framerate. (though admittedly, I haven't tested it in CPU-bound situations)

I would assume it has to do with bounds checking. D3 only renders a model if its screen bounds intersect with visible screen/portal space. What do the bounding boxes look like? Try checking with r_showViewEntities to see their bounding boxes. I think r_showInteractionScissors is intended to debug shadow culling, but it may also be applicable to whether or not an entity is rendered on screen. I also agree with Solis that a poorly placed origin might have that effect.

Gil: for the life of me, I've been trying to remember why we are using images instead of models in inventory in the first place, for two days now. I searched, I concentrated, I browsed design docs, but I haven't found it and can't remember. Does what you said about the compass above apply to all models in inventory, then? Is it coded poorly, so that models can't be dynamically changed, or is that just a D3 GUI limitation, or...? It's a shame, because a modder could just drop whatever model they want into inventory and have it appear, rather than having to make a bunch of images. I know, we've been over this before. Sorry, my memory is non-parity.

I went to a talk where one of the artist guys from Bioshock demonstrated his workflow when creating a model (it was the flying security bot thing that looks like an art deco motorboat engine - in fact such an engine was their inspiration for its look ). It was insanely complicated. He didn't have just the ordinary diffuse, normal, and specular maps - I forget what they all were, but there were about 4-6 altogether, including a baked shadow map. The end result looked phenomenal. So yeah, the artists working on Bioshock are amazingly talented. Their setting helps a lot too - art deco in a partially-flooded undersea world. Genius. They're not going for a realist look at all, which I think is one of their strengths. It really does look like it stepped straight out of a painting - rich saturated colours, patterns of light shining through the water onto the walls... very unreal, very cool.

About the compass--do you think your pitch method would work with a more realistic compass model, like the ones Ascottk posted above? If so maybe we could have the best of both worlds.

@Ascottk: Those icons look great! One thing that I think needs to be tweaked is that the potion icons need to be be fully opaque, at least for the metal end-caps. (any transparency should be due to the tdm_inv_opacity cvar) The reason I'm interested in working with inventory icons, is because I'd like to experiment with subtle animations, just to see how they look. (though I expect the Thief crowed would get annoyed if they were too obvious) For example, you know how the in-game potions ripple? We could have the potion icons subtly ripple in a similar fashion. Also, if we set up the materials right, we could provide a way for mappers to create arbitrarily colored potions without needing to add assets. @NewHorizon: The reason it doesn't pitch much is because it's just a flat 2D icon that distorts itself to pretend to be 3D (like how old SNES games used mode7 scaling to simulate 3D views) and if it pitches too much the illusion becomes obvious. I made it that way to avoid using a 3D model, so the inventory GUI wouldn't need special code to handle the compass. (which could make it more complicated) In fact the compass is sort of intended to illustrate the power the inventory code will hopefully give mappers - the compass uses no special code at all, so a mapper could have designed it as an item for their map without needing to modify the SDK, HUD or any existing assets. They'd only need to create some new images and write a script. Edit: Actually, it might be possible to make an improved compass icon that would allow for full pitching...

It would have to be 3d to satisfy the pitch crowd. I wasn't suggesting it had to look exactly like that, but something with a circular area that looks more compasslike. Here's another, somewhat darker, possibility: (btw, if we made the compass a realistic model instead, we could also use it as a prop item--something to consider)

Gil has a rough & working compass image that rotates & pitches as you look around. It's on test_inventory.map (the model is one of the potion bottles on the floor). It works very well.

The model we have now uses a different bone structure, but it isn't set up for Motionbuilder's character control/rigging system like the one used for the throwing animation was. As a result, you can't use effect pinners or simply select bones through the character control panel (you have to use the navigator instead). It makes the process take quite a bit longer and sometimes it doesn't look as nice, especially for animations where you need to move the feet or have pretty much any lower-body movement whatsoever. I've been trying to figure out how to set it up correctly in motionbuilder, but I'm not very familiar with Motionbuilder and I'm a bit slow to learn new programs, so I haven't had much luck.

Actually there's an offset in weapon_arrow.def: model viewmodel_arrow { mesh models/md5/weapons/shortbow/shortbow.md5mesh //offset ( 6 3 -3 ) offset ( -10 0 -6.5 ) anim raise models/md5/weapons/shortbow/get.md5anim { frame 1 sound_weapon snd_bow_unsheath } anim idle models/md5/weapons/shortbow/idle.md5anim { frame 1 object_call ArrowVisible } anim lower models/md5/weapons/shortbow/putaway.md5anim { frame 5 sound_weapon snd_bow_sheath } anim attack_start models/md5/weapons/shortbow/drawback.md5anim { frame 22 sound_weapon snd_arrow_draw } anim attack models/md5/weapons/shortbow/fire.md5anim { frame 1 object_call ArrowVisible frame 2 object_call ArrowInvisible } anim tired models/md5/weapons/shortbow/tired.md5anim { frame 1 object_call ArrowVisible frame 14 object_call ArrowInvisible } anim cancel models/md5/weapons/shortbow/cancel.md5anim { frame 1 object_call ArrowVisible frame 14 object_call ArrowInvisible } }I think it can be lowered.

Yes, I saw that a while ago when it came out as part of a svn-commit email to the mailing list. I actually made Shaderman aware of our Model Selector as well, when it came up in a user request. I think they might have some difficulty integrating it though with all of the application-wide changes we have made.

ok ok... i never worked with the normal maps before.. this is because i never worked for a game. Anyway, i just took my 3ds max book. I'm going to study normal maps. Soon you'll have an improved model, texture and a normal map.

Yep, it's got to be all one model, and one normalmap.