Search the Community

Problem is that I haven't done anything with AI and models, so it would probably take longer with me. Since I'm the only programmer here at the moment, until Isht is productive again, I can take a look at it. Would be nice if you put that model into a testmap that I can use for this purpose, and give it to me. I never put an AI into a map, and I don't want to learn it now just for that. If it works as I think it should, then it shouldn't take longer than a few hours. Unless the animations don't screw it up, which I'm not sure of.

LIKES 1 lower memory usage compared to doomedit 2 camera movement 3 the direction right click is going is a good direction clean but useful 4 I like texture menu just loads all the textures I select. Dislikes 1 entity inspector missing usage information. (Very helpful if it was available 2 Entity inspector missing create button 3 Entity inspectors is missing GUI, SOUND, SKIN, MODEL, preview button and preview window. 4 I miss pressing J to bring up the light inspector 5 I miss a separate light inspector that works outside the entity inspector(wht you get when you press J in doom edit Though the entity inspector does not have usage information available if it does get added it should expand on doomedits limited usage information by giving both side of the usage example: When you add a property to a target_x and trigger_y must have some other property added before it can trigger target_x. but you don’t know that until you read about it in trigger_X So I can’t remember exactly what property it was but it was like my example and I would have loved to know the other side of the usage information…anyways that is how I learned about the triggers and targets and gui and stuff. One night I sat and read the the usage and tested it in a test map. I suppose lots of us learn best when we can figure it out. Sometimes we can even learn a better way of doing something just by reading the usage information provided. And the key value information provided inside entity [like how to set gui_parm3 to name the area.]

Is it worth it? Just wondering about squawks. It's okay for me to just learn the Maya workflow - I'm not having to model in it, just export stuff. But if you're an artist who's modelling, it would be ideal if you could stick with your tool of choice.

As a QA thing, we should put on that list (or some list, for some future task) - each model should be checked to see if the polycount can be improved. A few characters, people have brought up randomly in the past that the polycounts were much more than optimal, but it's never been on any to do list or anything yet.

That's probably our plan B, since it would be a fair bit of work and isn't as flexible (heads may line up great on one model but not another, frex). Spar, when you say it should be pretty easy, does that mean easy like, "I can probably whip it up for you guys within a day or so," or easy like, "Someone else who has the time to figure it out will probably be able to do it at some point"?

Yep, that's exactly how I did it for the Model Selector, and how I would do it for this also. The dialog widget is created on first use and then just hidden/redisplayed every time afterwards.

I finally got the thief working. It appears to be the right size, but shouldn't the feet be placed directly on top of the origin, the way the elite model is? Otherwise the character will be floating off the ground, won't he?

After updating it works even less than before. Now I just get a black box. edit: Well, I think I see the problem. The animations and model have been put in the models/chars folder instead of the models/md5/chars folder, which is where the def file correctly points. edit: I'll fix it on CVS. edit: Hmm, can't tell whether it was successfully fixed on CVS or not, as it didn't register as a new location for the files. You may have to move it manually if it didn't work. I consider this all an annoying use of my time.

That's basically it, except it is recursive because adding "a/b/c" requires adding "a/b", but "a/b" is itself a child of "a" which may not have been added. If you didn't keep a cache of strings->tree entries, you would probably find this is O(N^2) complexity as you had to scan down from the parent for each new entry, checking if every ancestor was created every time. I'm actually quite pleased with how quick the model selector is when it does this - only a few seconds delay on my system the first time it is created.

Building the hierarchy from a list of "a/b/c" strings which may appear in an arbitrary order is decidedly non-trivial if you want to do it in a way which is neither incomprehensible nor appallingly slow. Fortunately I already have code to do that for the model selector (actually it's mostly comments, since without them I can't understand what the code is doing) so it shouldn't be too difficult to genericise this for use elsewhere. I wouldn't want to omit classes entirely; a class that is only used for inheritance would simply appear as a "directory" and would not be created by the user in most circumstances (this was the same in Dromed as I recall).

Nothing in that you don't already know, and it doesn't mention anything useful, like assigning images to the model in maya so you dont' have to mess witth he shader paths in the md5 file, or anything about IK setup, or anything about heads, or and thing about setting up the eye target bones.

Hey! That's a model of me I made for my senior recital flyer. Oh well, beauty is in the eye of the beholder . . .

Beautiful! This is exactly what I need! I wanted info on how to do the moving bone thing to tell Doom how the model is moving during the walk cycle - anyway, it's all in that doc plus it's a much more compressed version of exporting etc than the previous exporting tutorial doc we've been using. I'm going to post a thanks or something.

I did ready your post properly. My point was, that we asked here some questions, which apparently never got answered. I know that she can model. You may have noticed that I even answered on one of her models so I already knew that part. A team member is not only expected to be able to do his stuff, we would also like to know how much time he can contribute and if he can do other things as well.

Because I did exactly what you just said, and the thief model came out bigger that everyone wanted it. The reason I got spring to make the chart is because we can be absolutely sure they will be the right size he said. We've been through this already in the thief resizing thread. Anyway, I thought you were okay with this?

This is a little old now, but might as well freshen it: Likes: Love the camera view, works the same as GTK Love the texture view system, except that caulk often disappears for some reason when I hit U to show only those on the existing map. This is annoying since I have to reload common, and once caulked, need to reload all the darkmod textures. There is a way around it, but it doesn't seem to always work (show all). Love the feel of it, its exactly like GTK. Absolutely love the texturing method, though there's a bug in there when textures go fuzzy and u undo, it crashes. I like the right click menu, no where near as crowded as gtk1.5 (I never used doomedit, I hated it). I love the model viewer. Absolutely love it. Dislikes: I miss J key to toggle the face and brush colouring. In GTK, J on (brush lines/texture faces selected, patches selected when they are red) toggles thru the red disappearing, or the red lines around brushes disappearing in cam view. It was useful for texturing brushes and patches by seeing it without the red) I miss the [ & ] keys to alter the grid size I've not done much with entities yet, still building. However I did have a look at one, func_door. I gave it some of the standard keys I used to use for doors such as lip, wait and speed. These were not recognised. Lip I can understand with rotating doors. I absolutely hate the entity editor. Can you do it like GTK did? With a dialog, that allowed you to enter all the keys one after the other just with the enter key. In the current one, I have to click (all properties), then click add, then type in my key name, then the value, then I have to click on the white somewhere before I can add another one, then I have to repeat all that again. Much better to just be able to select the typing part, type in the key, then the value, then hit enter to enter a new key. Not sure if your going to add the angle buttons GTK had, but I miss them too. I miss autosave - I've mentioned before it doesn't work. Other than that; I am totally in love with this editor. Venus

Yes, that's something that needs doing. I will add a task to upgrade the filter system to allow arbitrary objects to query whether they should display arbitrary textures, and then it is a simple matter of getting the model rendering code to use this function.

Would it be possible to have an option to toggle off rendering of the 'collision texture' in the model viewer? It's handy to be able to see it, but when you're trying to view different skins, it's a pain in the ass.

That's the trickiest part of the model. There's actually 4 meshes in that area & if the weights for any of them are off, then the clipping starts. I'll fiddle around with those & resize the hands as well.

The latest version of DarkRadiant is now available at Sourceforge. http://sourceforge.net/project/showfiles.php?group_id=161727 Enhancements * Model selector with preview * Texture browser now has toggle to show all textures at a constant size * New context menu option to convert brush selection into a func_static * textures/common/collision is filtered out by Filter->Clips Bugfixes * Fixed segfault when loading certain ASE models that contained some submeshes with vertex colours and some without * Fixed textures with mixed case names showing as "not found". * Statics created from brushes now have origin key set correctly.

Aright, I've UV mapped and almost completed (diffuse) texturing on a model. That's gone good. But should I make specular/diffuse/height maps, or just a diffuse maps Normal maps? I don't know that much about radiant, so I'm not sure what it is you all need.

Well spotted, that's a bug. Actually I forgot to add code to set the "skin" parameter when you finish with the modelviewer and create a model. The fix is in SVN for the next release. Eh? It does render skins - are you referring to the problem New Horizon mentioned above? Very possibly, I would be surprised if undo did work correctly with texture alignment and other mathematical transformations. Can you be more specific? Does it just not do the save, or save to an unexpected place, or what? You can choose a different pixel size if the "constant size" option is enabled. This can be configured in the Preferences dialog.

WOW, I love this model viewer... as mentioned, lil bigger would be cool, and ability to render skins would also be cool (I can see myself easily forgetting if I've got the right skin on or not lol)... Other than that, I love it... thanks heaps While we're on DR, I've noticed a bug. When you apply a texture to a surface and are trying to get it to look right, if after doing an axial a couple of times (ie axial, then fit, then axial etc a few times) then try to undo, sometimes it locks up, and crashes out (losing what I've done). Also, the autosave doesn't work - I assume your going to get to that eventually. One other thing I'd like to see is the ability to choose a different texture size in the texture viewer ala gtk ie a % would be cool. Thanks... awesome job. BTW: Those models are fooking awesome, I was always disappointed with the thief models (and maps) but looking at these, its going to be amazing :D:D:D:D:D Venus

To use test model; Run the mod, start any map, type "testModel tdm_ai_thief" to cycle through the animations, keep typing "nextanim" If you agree that textures should go in the mesh folder they belong to, then materials should be grouped in a similar fashion, for characters at least; since character materials just point directly to a single texture each. So we should have a material file for each character mesh. tdm_ai_thief.mtr tdm_ai_citywatch_elite.mtr etc... And the folder won't be difficult to sort through if everything is named correctly. Its just a matter of scrolling past the stuff you don't need. Same as the def files in vanilla Doom 3. monster_demon_archville.def, monster_flying_cacodemon.def, monster_zombie_bernie.def It's like using a phone book. You don't want monsters, scroll past monsters. You don't want demon monsters, scroll past monster_demon.

Woohoo! I *finally* figured out how to get the grandfather clock animation working in game. Turns out it had been set to "anim" "idle", which only starts the animation when triggered. It needed to be changed to "start_anim" "idle" in order to start playing when spawned. Now, the remaining problem is that for some reason, the gfather clock has no collision information--you can walk right through it. I assume it needs a collision model of some kind, and some kind of surface type information so it registers as wood when hit (by arrows, etc). Any ideas about how to handle this for a md5mesh?