Search the Community

dear DOMARIUS thanks for that link. Actually i could model this blackjack right away but it may take little longer to make the animations for engine. I mean i m still in the learning level. Once i got the basics you will get your animations in no time... (PP) (*) So if you guys need that meshes right away let me focus on that and upload along with the other objects... Best ... (*) personal promise

Well of course the models won't look as good in-game. THe single biggest difference will be the lighting. THe D3 renderer is worthless shit, it's as simple as that (when compared with the Lightwave renderer that is) Though having said that, some of the doom characterss look pretty good, even though they only have one 512 texture for the whole head and body, and the models themselves are low res (mostly around 2k polys, that's even lower than UT2K3 models, and UT's models have two 1024 textures per character as well) It's just a matter of working out the normal mapping and the best way to apply it, that's the key in this engine. I suppose I can hook one up and shoot it in-game as a static mesh to see what it'll look like.

THat's another great piece. Reminds me a little of my NB pirate with the one piece mask and hood. Do you paint these digitally or the old fashioned way? Cloaks are not hard to model, it's just animating them or a game engine that's the pain in the ass, especially for a game like this with all sorts of sneaking. crouching. mantling, and climbing.

It is a pretty good program. Until two years ago (I think) it was proprietary. The company went down and the developer collected money to buy the source free from the company owners (or partners or whatever). So now it is fully GPL open sourced without the game engine. This couldn't be released but it is reprogrammed I think and now it is available again. IMO it is a VERY good program and you can do serious stuff with it. And it has been much improved since it went open source.

As Finger said, this would be done with a particle engine. And as Spring rightly points out: This is something that can wait until the core features have been implemented. This is also the reason why I don't fix the doors right now. For our purposes it works and we will have to do a lot of polishing later on.

I had an idea that may make everyone happy. I don't know if I could buy into the destructive force of a rag burning on the end of the arrow..[ sorry sparkhawk ]..but how about this. Since these crystals have somewhat magical/ enchanted elements...it might make sense that they do not become active until they are drawn. For example.... Player selects a water arrow. As the arrow is drawn back on the bow...it slowly begins to glow that familiar blue color and a drop of water rolls off the tip of the crystal. For a fire arrow. As it is drawn back on the bow it slowly glows and then a flame erupts around the crystal. In both situations, the crystals are completely darkened before coming into contact with the bow. Should be possible with the D3 engine. Essentially, some of the more volatile elements could have a small animation as the bow is drawn back for firing.

No. When you look at T2 then you will notice that it tilts (or is it yaw?) as well, indicating the players absolute world orientation. So if you look upwards the compass moves accordingly. Nevertheless, the engine doesn't know that and it would accept that model. You always have to have solid models with proper thickness. No single polygonthick models.

DeepO is talking about things which are bad and good game modelling practice. Things which improve performance. Basically, any game engine likes nice neat rows of triangles which it can render all fairly easily. It doesn't like to have them all bunched up unevenly; it doesn't read well. Also it can lead to clipping problems, that sort of glitch.

That's what I've always said. BTW, you asked, so I spoil it for you - YES, the scenery does change eventually. Well, the tension comes from that a monster can spawn or break out behind your back at any time, but what makes it scarey is that it looks so damn realistic. This game engine is so awesome. So awesome that they didn't even need to make a real game Heheh. Doom 3 is okay. It's not like the repetative battles are actually hard. I just played my way through with a frame rate that was 4-8 fps half of the time and 15-30 fps the other half of the time, and every battle can be played the same way as Doom 1 and 2. Each monster has a "best" way of killing it, that you soon learn: Imps - Wait till their fairly close, dodge the last fireball, and run right into their face and fire the shot gun. Can even be done easily with multiple enemies around. Etc. etc. I won't tell you my tactics for all the others, cause I'm not sure what youve' seen so far (so as not to spoil it), but they are all as fairly straight forward as that. And then the general tactics - which basically consist of - if there are multiple enemies, backtrack to a choke point and shoot them as they come through one by one. (The level designers obviously knew about this, so sometimes you open a door and find some enemy in your face that wasn't there before. It's usually just a soldier or imp, and their main weakness is a shotgun blast to the head. Works really well.) Or if stuck in a tight spot, run to the nearest corner and jump out and shoot them when their footsteps are loud enough. I don't know what exactly you liked more about Doom 1 and 2 over 3. They played exactly the same way as Doom 3, and a few slight scenery changes that were really just different textures. Everything still looked like the same old boxy graphics. Doom 3 just has more cooler features, like better graphics and physics. And when the scenery does change, it REALLY DOES change.

Well, the final textures would be applied via the material so this wouldn't matter. Of course. But I don't know how this is done when more than one texture is used. How do you tell Doom3 where each texture should go? UV mapping just tells the engine how to apply a texture, but not which one should go on a particular spot. Oh! Or you must combine the multiple textures into a single one and then UV map this, right?

I was reading through some of the SDK development kit, and noticed that Doom3 supports random sounds. That is, there are half a dozen different sounds for bullets hitting a metal surface, and the engine randomly picks one each time it is triggered. I noticed in our list of sounds, we haven't specifically talked about multiple versions of a particular sound(other than dialogue, of course). Do we want to do the same thing? And if so, for what kinds of sounds? I personally think this might be a great idea for things like water arrows (heck, even noise arrows), or other sounds. Opinions?

Is there any collaboration going on at all? I ask because the SS team will want to have frob implementation too (DromEd/ShockEd and all that). In fact there are probably quite a few things you guys could share as both teams are making mods that ape the Dark Engine in some way.

That should already be taken care of by the D3 scripting engine, which is syntatically very similar to C and even supports objects. Or did you have something specific in mind that is not covered by that?

well question is, how many AIs will be in vision of the player ? In D3 there weren't many enemies in comparison to other shooters ( I just say serious sam ), but think of thief ! How many AIs can you see at the same time ? Even if you run through a whole mansion there won't be more than 10-15 AIs persueing you - I think the engine is able to handle 10-15 AIs with a 1024x1024 skin. At least for people, who play with high quality - I remember that D3 is scaling down textures on the lower details-settings anyway.

I had another idea while I was working on this. I realized what the above version was missing was a middle-ground. The clock is foreground, and the city is background, but there was nothing in between. Looking at BT's latest wall (very cool) made me think of a city street. The tunneling effect that I liked so much in Ren's parchment picture could be created by a city street using an in-game shot. This would accomplish a few things: 1. It gives an immediate feel for what 'our' city is like. 2. It has lots of depth (artistically speaking) 3. It showcases the engine graphics right away. 4. It's fairly simple, and doesn't require tons of art production. 5. It can still capture the feeling of the player 'being' the Thief as they look at the menu (at least to some extent). The version below obviously uses the T3 picture, so we'd have to create one of our own. But it gives you the idea. What do you think? Should the clock still be a part of it? If I can put some gears around it that could turn as options were selected, that might be good.

sound shaders, my dear friend Pak, are basically like material shaders in that they tell the engine how to mix the sounds with other sounds and which sounds to play. So you could have a sound shader which is called, but actually references several sound files, and randomly plays one each time, for instance.

I will start on the noble man if that’s ok with you springheal. what is my triangle limit for this particular character? I will use a 512 by 512 texture size and can I use the unwrap uv's in max for the texture projection ...or do you use a different method for the game engine ?

Please forgive my ignorance but what do you mean when you say brushes ..I have never heard that before. I understand the rest of your comments….this is exactly the reason I want to work with you guys so I can learn a little more about the transition of 3d 2d elements into a game engine

Polygon limits? For maps I'd go about 8000-10000 brushes, with about 15-20,000 tris in a single scene at most. For models you'll have to talk to DeepO or Oddity, they know far more about that than I do. Texture sizes...our average texture is about 512x512, rarely lower than 256x256 and never over 1024x1024 since the engine automatically compresses any texture larger than that. Keep in mind that all the resolutions have to be divisible by 2, like 128x512, 256x1024, 512x512, ect... You should be able to get the hang of it pretty quickly, since you're already good at modelling everything here will come second nature to you.

And I forgot to add. This option would probably be of high interest to ghosters. They tend to come up with all kind of crutches to get around the engine limitations because it does NOT support putting stuff back. Especially when playing on higher difficulty levesl this could be interesting. And I think if we are able to put an item back, we should make use of that for the game as well.

I think there is a problem with putting something back. It is the physics engine. My guess why this doesn't really work in any game (none that I remember at least) is that it requires special coding to provide for it. If some object is standing in a i.e board, the character can not reach it really. So this means he he blocked by the bounding box of the board. To take the object the code simply looks if the player is near enough and then removes it from the world into the inventory (or players hands). If you would have to put it back, this would mean that the player would have to be near enough. But the bounding box prevents this. It would require a high precision to place the object back. But I think we can do this by either providing a seperate button OR by assuming that the player wants to put it back if the view vector and the distance is in a position near enough of the original position. We cimply must store the original location of the object and replace it in the case that one of the above is true. The nice thing is, that, if we allow this, we could even programm the AI to recognize moved objects. It could work like this. The player takes an object (i.e. a book). When he wants to put it back the object is placed randomly within the original region. If the player holds the button down for a longer time, the object will be adjusted and shift to it's original place. After a certain time it will reach the original place but that takes time. If the object is carelessly placed then the AI could recognize it. If the player takes the time the AI won't recognize it afterwards. What do you say?

Oh God noooooooo, what have I started. :lol: If loot is distinct enough from junk like in the orginal games we really shouldn't need it. I don't want to say I'm vehemently opposed to loot glint...ahh hell, I am. I think part of the reason they had to use loot glint in Thief DS is because they shared textures between so many different items that everything blended in, but that shouldn't be a problem for us. I have a few alternate suggestions as I don't think it's fair to drop it completely as I'm sure some found it quite useful. My first suggestion is to have a distinctive loot texture that will allow the player to learn what is valuable quite easily. I think with the doom 3 engine we also have specular maps on our side, so junk can be completely dull when compared to loot as well. Sort of like having loot glint, but just not the obvious kind. My second suggestion is that perhaps loot can also have an extremely subtle glow..could that be done with shaders too?

That's right. I was looking at the sample screenshot that BlackThief provided for his textures and the characters of T3 look rather gameish. The models from T2 looked much more lively despite the poorer gfx engine.

Not necessarily. I'm sure the FM community at large will be more than happy to build their own custom content. Much better to provide a solid set of IK bones and walk (etc.) animations that can be customised than multiple variations on everything. It is, aftar all a (sort of) fairly streight forward proposition to plonk a crayman model and skin on top of a zombie bone-set and call it a beasticle. I hate to be the nay sayer (again) but we really should be concentrating on getting some basic characters in the Dooooom engine, getting them animated and ironing out all the problems as a priority. Hows about applying some thought to character animation and poses springheel and Darkness Falls. Something a bit like a story board (but for individual actions) that can be used a guide for key frames. How about giving some detail on the existing concepts. Or providing side and front views to make the modelling process that much easier.... Grrr. I really don't like making this point over and over because the concept art that you guys are producing is a treat. They really do look fantastic. But these are parallel tasks that can be taken up at pretty much any point. There are mission critical tasks that need addressing first. err, yeah - anyway. what the other guys have said. The grey and green colours are a bit alien-eseque. Are these things blind/poor sighted or do they have big reflective eyes for seeing in the dark? Big crayfish tenticles would be cool for feeling your way around in the gloom. Spiders. I want Spiders.

hmmmmm, not for Doom 3.I have some Jedi Knight Stuff, and possibly some call of duty maps. As I've kinda tried to show in my stuff, I understand the Doom 3 Engine and mapping ect, I just don't have anything in it yet (I got it pretty late, just recently finished) If you'de like to see some of the others I aughta be able to show some. (note: along with texture I also do interface art, and understand .guis) If you have MSN we could discuss more