Search the Community

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.

Well, that's not the way models for games are made. It's better to treat it as one model and unwrap the UV coordinates, so you can easily create texture for it. I'll get some examples to illustrate it.

there will be 5 normal maps, since the oil lamp model is made of several pieces and 5 of them have extra detail in the hi-poly version. Ok?

I don't need the highpoly model, just: --the lowpoly .lwo or .ase --the normalmap.tga --the diffuse.tga --the specular.tga

There's also the possibility that the collision model is overriding the material attributes so an additional definition would be nice

Looks pretty good! At first I looked at the photo and thought "Oh, my god! This looks like a photo!" until I realized that your model was the small image.

Thanks and thanks for moving the thread. The pew was the fifth model using the gen_texture layout. The first four were the handrails I did a while back.

well, i'll continue to model things, i like doing this, but maybe i can make a map too in a future.. no?

I thought you were applying as a modeler? It's more important that we fill out our assets right now....if there's no toolset, then there can be no campaign. It sounds to me like you're more interested in being a beta mapper than a contributor. It's a bit of a let down for me personally, because generally if someone applies for a position by displaying their modeling skills...it means they wish to model. At any rate, it would be most beneficial for the project if you were to help us fill out our asset themes. We certainly need as many props as we can to populate the game world with objects. As I said earlier though, there is really no difference...anything you make WILL be used in the campaign later....you're still contributing to it in the end, it's just not being worked on right now.