Search the Community

Wow Spring, that's awesome. Seriously, with skins...you would think it's a brand new model.

I noticed a couple of problems with the Skin Chooser that need fixing: 1. On Windows the dialog widget displays too low, with the buttons not visible. I have fixed this by making it appear centered on screen rather than over the entity inspector window. 2. There is a segfault on shutdown after the Skin Chooser has been used, owing to the attempt to delete the preview model which in turn releases the shader after the GlobalShaderCache has already been destructed. I will have to investigate the best way to solve this. EDIT: Whoops, there's another one as well. The window does not correctly handle the "window close" event when the upper-right close box is clicked, and cannot be re-shown afterwards.

I don't think our old sounds would blend well with these, and I would truly prefer not to mix and match. There is a distinct difference between them. Our old steps don't have that classic Thief 'ba-dump', heel-toe sound...they're just 'clunk', as if the foot is dropping straight down onto the floor. I had them all enabled when I first added the T2X steps and it really sounded horrid. This set uses 4 steps for each material type (Thief Standard), and they cover all the sounds we already have ...plus quite a few we didn't. There are also 'jump' sounds for every material. We just need to have the model setup to use them. I still have some fine tuning to do...I'll also upload my test_footsteps map. In regards to adding more variety, this shouldn't be too hard. In the Thief games, the AI used a slightly different set of footstep sounds...they were the players steps lowered in pitch so that they sounded a tad heavier. I'll whip those up and we can try them out.

i've exported the animation but i can't get the model with animation to work. Exporting works fine but for example, when adding the .md5anim into the existing citywatch def file i get a message saying "different number of joints". md5anim file: http://208.49.149.118/TheDarkMod/Animations/failedKO.md5anim

Heh, I'd play multiplayer with you guys but I'm unsure about connection speeeds from Europe to Australia. But i always thought you could pause in the multiplayer games; I'm sure i remember seeing it somewhere that the host can pause whenever he likes and also assign that ability to other players. Sparhawk if your looking for some extra tools that might add more life to the game you should try looking for a group called TeamBG. I'm not sure if they're still around but a while back they had a website devoted to developing tools for the Baldur's Gate and Icewind Dale games. They had things like savegame editors, you could create items, creatures and even areas, and edit all your characters statistics etc. They also had custom items, races and kits available. I think alot of their stuff can be found at www.sorcerers.net Much of the items can be used for cheating and whatnot, but i remember i used one savegame editor to change my assassin's appearance from his normal avatar to the model used by the shadow thief assassins; it looked awesome. You can make your characters look like Bodhi, Irenicus, Sarevok or even a goblin. I can't think how hard it would be to solo the Baldur's Gate games. I mean, christ, how the hell would you fight Abazigail in ToB as just a lowly friggin thief? Hell I had trouble using 4 fighters and 2 mages, i don't even want to think what it would be like trying to do it on my own. It'd probably take 3 times longer to finish the series. Nyarlathotep, Torment is hard to find but well worth it if you like epic rpgs.

She's been using pics of oDDity's models as a reference from the start. So whatever results we get from her is as good as if you told her. I don't think it'll be that noticible during gameplay, not enough to warrant re-working anything. Look at these two guys; http://www.realtimecg.com/template.php?id=...zm.php&n=18 http://www.realtimecg.com/template.php?id=...us.php&n=18 I didn't notice that one had mitten hands and one didn't untill I went to look closely at the topology so I could learn something to make my own model. I really doubt I would have noticed during gameplay. I mean I might eventually make the observation at some point if I saw enough closeups of hands, but it certianly wouldn't look strange during gameplay.

We have the original MBs for all of the models though, so we don't need any MD5mesh importers *hits head* It's not impossible, just a lot of work. Everything will have to be re-rigged and re-UV-mapped. And at the same time, if we want to make decent thief levels, something has to be done about it. BTW, the 3DS Max MD5 importer works REALLY well, bones and rigging intact, so, if we ever need it... there it is. Well, we'll get squawk's template model pack on the weekend, and then we can all take a breath and think about where we want to go with the poly count of everything we have. I suppose if squawk's templates are made lower poly, now is the time to do it, before anything is made from them. Maybe the switch to mitten hands can be a part of that.

From the other thread: I looked briefly at the md5 importer for Blender, and don't have much hope for it. Even if I did get it to work, I'd be willing to bet it doesn't preserve UV maps. So, to any modelers who might know: is that really so tragic as it sounds? Can the old UV map just be "reapplied" to a modified and exported model?

Yeah, it really bugged me that everybody decided to switch to mitten hands when there were plenty of less noticeable things that were wasting far more triangles... For example, why the heck was this belt-buckle fully modelled? Altogether, including the center part and both sides, the belt buckle should have taken 2, maybe even 6 triangles (by having the belt-buckle drawn with an alpha-test material - the design philosophy of D3 is to put the detail in textures, NOT model them!), but instead it looks like it takes 100. The models are full of things like this and everything is subdivided more than necessary... such wasteful use of triangles is why a single guard entails a 20 fps hit! Don't get me wrong, oDDity is an artistic genius and I wish I were even half as skilled as him, but I consider his judgment for low-poly modelling to be ... exceptionally lacking. Edit: Sorry... this has been building up and I just felt like venting.

Here is a plant (bamboo) model

When I say kinematics I mean things like velocity, forces, acceleration, and doing everything in vectors. You might already have a good understanding of this, I don't know: For example, say you have an object that starts a point s0, which is a vector: s0 = (s0_x, s0_y, s0_z) [meters] Now you apply a constant velocity v to it at time t = 0, and v is also a vector: v = (v_x, v_y, v_z) [meters/second] The new s as a function of time t is given by the following equation of motion: s(t) = s0 + v * t Momentum is defined as mass * velocity [kg * m/s]: p = m * v Momentum is kind've a measure of how much something wants to keep going the way it's going. It's harder to stop a heavier object than a light object, and it's harder to stop a faster object than a slower object. Now, velocity can change over time, and that gets us into the realm of acceleration, forces, and impulse. Acceleration is the rate of change of velocity. For a constant acceleration a that turns on at time t=0: v(t) = v0 + a * t Force is defined as rate of change of momentum. Since momentum is mass * velocity, and we're only looking at one object, our mass is not changing, so force ends up being mass * change in velocity, which is acceleration: F = m * a In physics, usually what you know to start with is the force. From the force, you can extract the velocity and the position using Calculus, assuming you know the initial velocity and initial position (at time t=0). Note that those equations only really apply to the net force. You could have two forces pulling opposite directions, and if they add to zero net force, F = 0 and nothing happens. If one is made slightly greater than the other, there's a small net force in that direction and it starts going that way. Kinetic energy is defined as: K.E. = 1/2 * m * v^2 Energy is a good measure of, say, how much damage something does. That's why I was saying that when AI fall, the damage they take should be proportional to the square of their velocity. That's all you need to know for simple mods to the D3 physics. It helps to have some idea of what's going on behind the scenes, the main thing being that the time variable gets quantized. Finite Difference Method In Doom3 and most games, they implement a physics model called Finite Difference Method, where everything is quantized by the time step of one frame in the game (nominally 17 ms at 60 FPS, but can be longer if performance is suffering). Note that if your rendering framerate goes above 60 FPS, the game physics simulation keeps running at 60 FPS, so it's indepenent of the rendering framerate in that respect. However, if you have some scene that hogs CPU to render and slows down FPS to 20, that will also effect the physics and you'll see things happen like a slideshow. That's why some things like bullets flying thru the air are interpolated between frames using the actual time, but don't worry too much about that for now. I can't really derive finite differences method in a meaningful way without Calculus, and it's also not super-important for doing the kind of work we're doing, so I'll just give the final equation without any real explanation. I've mentioned that we can start with the force and extract the velocity and position. But what if you only know the force at each t = t_0 + N * Delta_t, where N is the frame number? It turns out that there's an approximation that lets us predict how the position will change from one frame to the next, based on the current value of the force, at some time t_N: [For those interested, this can be derived from Taylor's theorem, approximating the derivative as a finite-difference and taking the first two terms] F = m * a = [ -s(t_N + 2 Delta_t) - 4 s(t_N + Delta_t) + 3 s(t_N) ] / (2 * Delta_t) Again, for the problem we're talking about, you usually know the force, and want to calculate how the object will move. You can use the above equation to approximate how an object will move (its position is given by "s"), due to some force applied to it in that frame, over the frame time Delta_t. You can't always apply this approximation. There are conditions where the time step is too large for what's going on and it becomes unstable. This is why ragdolls flop around like crazy sometimes (that and we're trying to drag them to a point they can't get to because they're blocked by something ).

Ahh excellent, glad it was something simple for once. Thanks for the help, I'll start converting the models after I tweak them over the next couple days. Oh ok, no problem. It would take a while longer to modify individual limbs since they have a large number of keyframes, just raising and lowering the whole model was what I was refering to when I mentioned the 5 minute tweak thing. I'll keep in in mind if I have some extra time and don't have any other models to work on...but that probably won't be for a while

Look for thug model on ftp. See if there are any houseguard files that might have the mesh in them as well

Here is a new temperate plant model, this one has flaws but I'm working on them.

All I get is the origin moving that results in a sliding t-pose (supposed to be walking forward but the model just slides forward). The animation looks great in the movies you posted. I could help resolve the import issues if you could post the fbx file. I know they're rough but the one that bugs me is the cautious walk. The arms should move in the opposite direction of the legs (when the right leg moves forward then the right arm moves backwards). Right now the arms go in the same direction.

Another thing - sometimes while free models in two axes models which were previously rotated using that 90 deg. rotation button, rotation reverts back to 90 degree. I mean - all changes done with free rotating tool become canceled. Any idea about that? Also - is there a way to rotate group of selected models according to one shared point, instead of separate points for every model?

Well, hopefully I'll be contributing a bit more now that I have a fully rigged model to work with. So I should be able to finish more animations at a quicker pace now, but I'm not sure yet how much time it would take me to do full animations once I get the system down. Out of those options, another I might consider is to put in placeholder/lower quality animations for some of the more difficult actions (or simply recycle most of them from other characters). That way, it's something that can be updated later without messing anything up, and would allow the people using the art assets in levels to have every animation at their disposal while still allowing it to look better in the end. I'm not suggesting we stop making quality animations for the characters, but given that I've seen retail games have characters that sink through the floor, bend their bodies in totally unnatural ways, and walk with their feet not even staying in the same place that they step, a few lackluster animations in the first release of the mod that are updated later on would probably be acceptable (as long as the poor quality animations are actually replaced eventually). I think it's a slightly more desirable option than cutting AI characters entirely. A guideline would be to expect about 5-10 seconds of higher complexity animation from an animator in a week (things like walk cycles, interactions, etc), with less complex actions such as idles or the lower quality animations extending that a bit. If you can figure out about how long each animation is going to take to be completed and then factor in how many you have, you can come up with a timetable for how long it would take to finish all the animations and start figuring out what would be the best places to cut back.

I can see you've used an extracted T3 model as a template for this, but we're really trying to get away from the T3 look. What happened tot he thug BlackThief made?

Try it now. I moved the origin two units up and moved the candle in XY so it matches the candleholder. The smoothing problem is probably UV coordinates problem - it gets screwed up while converting from .lwo do .3ds in Deep Explorer. Anyway - this candle model could look better, as Spring has mentioned before, so I'll do another texture plus new UV later. I hope it's OK for now for your physics tests.

The "red book" aka "OpenGL Programming Guide: The Official Guide to Learning OpenGL" is the best I know for OpenGL. You can get an older version for free from opengl.org. This older version covers OpenGL 1.2 (current ist 2.1) as far as I know, that should be enough for the basics. The newest version covers advanced features like shaders, frame/vertexbufferobjects etc. The red book is only about OpenGL, it won't cover how to load a model or how to implement playermovement. You may want to read a different book if you are interested in these areas. I read "OpenGL GameProgramming" which is good, but not outstanding. Last but not least: "Mathematics for 3D Game Programming & Computer Graphics" is a wonderful book if you want to get a deep understanding of the math behind rendering and comp graphics.

I'm just uploading candle model with modified CM. (candle2.lwo) Does it look right? Also - I'm not sure about the origin where it should be - at this moment candle and candle holder have the same origin point (at the bottom of candleholder). I just thought it might be easier for you so you don't have to adjust any offset for the candle...

--get healthbar working in HUD --see if there's a way to have healthbar fade after appearing --create houseguard skin for proguard --make nobleman model request

Okay, sorry, I couldn't remember if it was or not. Just to clarify, this should be a separate model from the default candle that's now used, just in case someone wants to place standalone candles with correct collision meshes. I think you've already been updating a separate file, but can't remember for sure. Also, it should only extend out around the sides, not on the top/bottom. Otherwise it would interfere with frobbing the base and might interfere with the top flame getting stim signals.

It should work in the Model Selector, but it doesn't work in game. This is a known issue that needs addressing, but isn't fixed yet.

I like the texture, but something still seems not quite right about him. One thing that bothers me is that he carriers his arms too far out to the side. The angle of his upper arms seem perpetually bent out, as if he were carrying two stacks of books under his arms. This persists even in the ragdoll state, which makes me think maybe it has to do with the model or underlying joint structure rather than any specific anim AscottK gave him. Disclaimer: This comment was made based on how he looked yesterday, before Ascottk's changes today.