Search the Community

I think if they need to be TGA to work they should be tga. Converting one at the time it is needed is a pain (OK, not that hard) but it won't look as good from dds to tga will it? Also, it would suck for modders if they had to figure this out anytime they wanna make a new material. I haven't read all the threads but other than file size there seems to be no reason not to have the normals be tga.

what about video card memory, would compressed textures allow for more of them being shown at once, or run faster? That's a pretty good reason

If five beginner modelers could be assembled, we could agree to create these sets and they would add up pretty quickly. Say we all decide to make punch bowl sets, something I started last night. So I make my "archetype", then make five to ten variations on it. It took me an hour to make the bowl and most of the ladle, a cup that can be cloned six times will be for tonight. Now, tomorrow I can tweak it and make three different versions, probably in 1/2 hour, a few more the next night, lets say for a total of six. Just different textures and shapes, a few minutes with the modeler and its done. With my colleagues, we would have a set of 30 to chose from in a week, actually much less if necessary. Then, the next week, its dining ware, then silverware, soon you have a pile of dining stuff. Then its kitchen stuff, then bedroom stuff. The reason to work on the same stuff is so that if problems crop up, all the noobs are roughly on the same project and can benefit instantly from advice from the more skilled and each others input. Plus all the numerical and aesthetic standards would be in accordance, with one person pointing out things to another to keep everyone moving in the same direction. I'd be happy to get a IM prog and help a noob to get started. After that we are both fucked. I have some time and sanity finally. Im getting paid leave from work so I can breathe for the first time in about nine months instead worrying about becoming homeless. It would be easier for me to stay on this schedule but its not really that onerous, cause after the first model is made its all tweaking. If anyone is interested in working on sets of items please PM me and we'll get going. If you can contribute one hour a night, and less on some nights cause once you get going some stuff is really easy to reproduce, you could help build up this repository of objects.

Thats right I think but these guys are pointing out that prefabs have drawbacks too. It seems best to go with individual items. If there is a variety, and with simple stuff it should not be too hard to produce, you could quickly assemble a relatively original scene. Enough to help immerse you in the story or setting. In fact, other than time and effort Im not aware of a reason why this level of work couldn't be done to order. I know thats a bold statement for a total frikking noob to modeling but its true. All those perfume bottles could be altered in a moment, all those makeup jars, it would be simple. A specialized design or scheme could be incorporated pretty much at whim. A mapper could ask for the same brush/comb set done in ivory or wood or whatever and it would take a few seconds of reassigning textures. Add a bit of variety to the brush/comb base set and you have quite a bit of diversity available, and so on.

Just to be clear, I agree that it's probably better to keep them as individual pieces, not a one-piece. Although I guess it couldn't hurt to test it out and see how it looks? But even then, I'd keep the pieces separate for other uses on top of that, making a one-piece mostly redundant anyway. (Also, I don't know how the object hierarchy works for Dark Radient, but there is a way to associate them as a family of related objects, right?) My main concern, as I already said and Schwaa's alterego repeated, is just making sure they aren't so small as individual pieces that they'll get lost in the game. But then again, as jdude mentioned, little trinkets like this really make the world more immersive and I myself have sized stuff down a little in dromed for just this purpose. There don't *have* to be absolute rules ... in the end it's about what looks good and performs well in-game, and there's nothing stopping little stuff from really bringing a room alive. I sometimes get annoyed when rooms in Thief look a little too "prefab", even apart from the shelf-life idea. Some objects just look like they were objects made for a game, although very often for good reason (poly counts or gameplay reasons, etc). The obvious dearth of tiny trinkets might actually have been part of that. I guess the point here is it's really a judgment call with maybe some trade-offs on different levels (aesthetics, performance, etc)... pros and cons looking at it from different ways. Just take a good look at all of it in-game, walking around like a player might, and ask yourself does this really work best for this object?

Lookin good, we do need stuff like that. A few crits, I realize they aren't done so this is actually a good time to mention some of this stuff. I agree, size wise some of those things seem a tad small. Even if it's a relaistic size it might get lost in game being so tiny. Even rings tend to be larger than life so they can easily be seen. (of course if they aare for an AI to wear...) Sorry if this stuff is known and or obvious to you. I would stay away from making too many one piece objects. Authors did like stuff combined in Dromed for the main reason there is a limit to how many objects can be on screen at once (125 I think). Seperate that try would be 20 pieces, together it is one. Also, physics in Dromed suck, we had squares and spheres. So that tray would be a one piece non-movable object. Dark Radiant however can handle as far as I know and unlimited # of objects per scene. So why have the same tray in every room? Also, the physics are great, so they player could blow the tray up with a fire arrow and all the pieces would fly (if seperate) and would all bounce ect correctly. In Dromed they wouldn't work as well. There are certain objects that can be combined and make sense. I made a carrot and will probably make a 'buch' of 3 or so. if they are tied together a player could pick them up and throw them as one piece. The tray however would look odd if it landed upside down and all bottles are still attached the same way. If you do want to make a one piece though, just export all of them at once into one file. ----------------- Figure out the normal maps BEFORE you make textures and export. Tons of detail can be added to a simple obj this way. But easier to do it the first time. Some of the little jars and stuff might be too high poly for such small items. One of those little ones probably shouldn't be more than 100 polys, maybe less. The bigger items there I'd say about 250 (comb and mirror, bowls too)

First, it's looking good. Second, are each one of those vials/lids on that tray individual objects, or is it more like a set piece, like it's all attached to the tray and you just plop the whole thing down as is? Sounds to me like Springheel is curious about some of those tiny looking vials and lids ... which look like they could get completely dwarfed in a scene if they were just used by themselves, as an author might want to if they were presented as individual objects. Or put another way, some of those vials on that tray look a little too small (in that screenshot, anyway) to be useful individually, although that size seems to good as a set piece, as you have them. But then you have the issue that authors might not appreciate as much objects that can only really be useful as part of a set-piece. They might appreciate the flexibility of using those vials as individual objects, so they don't feel hemmed in with what those objects are good for. Also there's the idea that pre-fab set pieces are very often the kind of objects in modding that start looking overused and worn-out the fastest, as most mods will stick to stock material, as we all know from seeing certain objects in Thief looking overused. At the very least, authors might like to be able to rearrange the vials so they're not in the same order every time. So then you might want to make them as individual pieces, and a little bigger so author's could have a little more flexibility in using those objects in fresh ways. Then it occurs to me you might have a prefab-esque set-piece, or smaller pieces to be used as part of a set piece, using those smaller vials (which still admittedly looks good), and bigger individual versions of them if an author wanted to use them individually for whatever reason. They might be more useful that way. Anyway, I'm just thinking aloud. The point is, some of those vials and lids look pretty darn small to be useful individually, but packaging it as a set piece (prefab or otherwise) has its own issues. Just something to think about. It all looks good.

Here are my concerns about that, though as a modeler, mapper and the main force behind setting up the .dds folders, you will probably have greater insight into this than I do, so just tell me if I'm wrong. Issue 1. Right now there are only a few textures being used with addnormals (personally I didn't know about it until you told me, and I assume others didn't as well). I'm hoping to make much more use of this in the future, however, so let's say I'm making a new model and I want to add a stone block texture to it using addnormals. I look through the editor and find the block texture I want. I track down the material name and enter it into my material. But it doesn't work. Why? Because it's a .dds file, though I had no way of knowing that while scrolling through the editor or material files. If I wasn't aware of the .dds issue, this could cause a lot of headaches. Issue 2. Since I DO know about the issue, I'd next have to retrieve the right .tga file from the hires repository and transfer it to the main texture folder. Now we have two copies of the same texture, one .tga and one .dds. That seems like an unnecessary waste. I could of course delete the .dds normalmap when I transfer the .tga version, but beyond the added potential for confusion, that leads to.... Issue 3. Compressing normalmaps has to be done with a special plugin that not every modeler or texturer is going to have. The plugin that might compress a diffusemap properly will not necessarily work on a normalmap (or so I understand). This could cause problems for people who aren't aware of this, making their normalmaps not work. I expect, to try and avoid this problem, some people will be uploading their textures as .tgas in the main texture folder (especially if some model textures are now going to go there) hoping other people can convert them later. So when we find .tga normalmaps in the main texture folders, how do we know whether they are there because 1. the person uploading them didn't make .dds files yet, or 2. they're being used in a shader with addnormals? Checking to see if there is a .dds version wouldn't help, as shown in scenario 2. Anyway, it just seems to me that keeping some normals as .tga and some as .dds is only going to cause confusion and make the texture folders harder to maintain. My vote is to be consistent and keep all normalmaps as .tgas. It seems like the only reason NOT to do this is to save space, but if we start using addnormals regularly, we'll probably save just as much space by not duplicating normals as we would be keeping some of them .dds. (Btw, do we know for sure that .dds files work with OTHER special keywords in shaders, like blends?)

That's right. Could you make another profile of the "Select All" command? It is also very slow and I'm curious what the reason is.

Funny, we all have different opinions besides the fact that they are indeed good models. my opinion in case you care I think PinkDot is right that there could be a little more detail. Of course it could go either way. If the maps are object specific more detail for sure. If however you were thinking of mod bloat (I like that term) and you just reused existing textures I'd say job well done. We don't have very many generic textures that can be used for alot of stuff so it's hard to do and get a good effect. I think the shapes are great as is and agree with Komag that you have the right shape for the axe handle, better leverage that way. I think the axe handle looks odd for different reason than sparhawk, I'm not seeing a rust anywhere. I think it looks odd because it is big enough to be a 2 handed axe, yet only one hand could fit on the handle. I also think the bent handle axe is too big, looks like a one handed wood axe to me, but is too big. Deffinately not a fightin axe so I wouldn't even have a large one. The silver fighting axe though, you could have a small one handed (just scale that model down 50%), and a 2 handed - as is but the handle should be 100% longer.

Nice little game, reminds me of Risk. After playing a few rounds, I would like to provide a bit feedback: - I dearly miss a Move All button (Right-Click-Drag?) to bypass the "Leave behind" window - A selection frame to issue a command to multiple ships at once would be nice - I like Holst's Mars, but after a while it gets on my nerves. Something less dramatic and more ambient would maybe be better suited for longer games. Also, it crackles and pops for some reason on my machine. The ogg itself is fine when I played it in winamp, so maybe the problem is with the vorbis module? - The graphics could do with a wee bit more bling. Alternatively, I could imagine a very "strategic" look (triangles for the ships, circles of different size for the planets, dotted lines, spacey background) to work well. You know, the stuff you'd expect on a strategic console in Star Wars.

As long as the concretes are not really duplicates, I don't see a reason why to remove them. If they are below par, it's ok, but removing them just because we have "enough" doesn't cut it IMO. After all, they can be also used to have similar surfaces without repetition.

Well, we do only have the muffin and cake (which I think is to be aced/replaced anyway) and your loaf which I don't have (is it on SVN, I thought I was up to date) I really think we need to start using subfolders myself, that's why I added that one. It's possible we will end up with 20 kinds of food, 30 dishes, silverware, pots, pans, bottles, sacks... Pretty soon we're gonna be scrolling thru 50+ things to find a loaf. I'm a firm beliver in organization and it needs to be sooner than later or we'll start getting map issue and it'll be too late later. Another good reason to sub-folder is certian objects have different props. If I'm building a level and looking for something to feed the player I don't wanna search thru pots and pans. I think that's a problem that we keep facing is lack of good folder structure from the get go. We have sacks in kitchen and under containers. Iwould've never pout barrels under containers, I can live with it but doesn't make sense to me. Containers should only be things that hold something for player IMO. I can find instances of this in each folder, graveyard has bones_... then way down the list skull. I'd personally rather open a graveyard folder and see gravestones bones debris stautes then if I want a gravestone I can look only at gravestones and search the 10+ stones, if I want statues I'd only look in that folder... that's my 2 cents anyway

I can get this super slowdown problem in either Doom or in Dark Radiant. I'm sure now I've had this before but dismissed it as a memory glitch. If anyone else gets this problem, the 'rules' to avoid it seem to be... . It may or may not be Nvidia graphics card related. . It only affects the loading phase of either Doom or Dark Radiant. . So far I've only noticed it if a grass texture is being used but I'm sure certain other textures will have the same effect. . Always open doom first BUT DON'T OPEN AND SHOW A MAP IN WINDOWED MODE (ie, if you DO open a map then go to the Dark Mod menu so it does not show.) THEN open Dark Radiant. . If you should open Doom first in windowed mode and also open and show a map in Doom and then open Dark Radiant then Dark Radiant might slow down so close it, switch Doom to the Dark Mod menu and THEN re-open Dark Radiant. . If you accidentally or for whatever reason open Dark Radiant before Doom with a map showing then select 'new' map from the file menu and (IMPORTANT) use the 'flush and reload shaders' button on the texture browser and THEN open Doom. When Doom is running then re-open the map in Dark Radiant. Once both are running OK then there seem to be no further problem so it's workable.

I have am chine setup in my living room which uses WLAN to connect it to my network. Otherwise I would have to pass a cable there (which in the long run might be better probably). The issue now is, that my neighbour also has a WLAN and our houses are back to back. I think this is the reason why sometimes my connection is extremly bad to my machine (as right now while typing). So I wonder if there are ways to improve this situation. Either by changing the frequency, shielding or maybe disrupt my neighbours waves without disrupting mine or similar. Actually I don't care that much if my neighbour is pissed off, because we are not really on good terms anyway.

radiant/ui/ortho/OrthoContextMenu.cpp: In member function 'void ui::OrthoContextMenu::checkMonsterClip()': radiant/ui/ortho/OrthoContextMenu.cpp:154: error: no matching function for call to 'SelectionSystem::foreachSelected(ui::ModelFinder (&)())' include/iselection.h:143: note: candidates are: virtual void SelectionSystem::foreachSelected(const SelectionSystem::Visitor&) const radiant/ui/ortho/OrthoContextMenu.cpp:157: error: request for member 'modelList' in 'ui::visitor', which is of non-class type 'ui::ModelFinder ()()' radiant/ui/ortho/OrthoContextMenu.cpp:157: error: request for member 'onlyModels' in 'ui::visitor', which is of non-class type 'ui::ModelFinder ()()'I get this error message that says that my visitor is no class. typedef std::vector<scene::Path> InstanceList; class ModelFinder : public SelectionSystem::Visitor { InstanceList targetList; bool onlyModels; public: ModelFinder() : onlyModels(true) {} void visit(scene::Instance& instance) { Entity* entity = Node_getEntity(instance.path().top()); if (entity->isModel()) { targetList.push_back(instance.path()); } else { onlyModels = false; }}}; But this is obviously a class. For completeness here the lines that cause the error: ModelFinder visitor(); GlobalSelectionSystem().foreachSelected(visitor); I have really no idea what the reason is, as this is really just a normal class. Any ideas?

These are my relevant DoomConfig.cfg settings, be sure the have normalCompression set to 2, this might be the reason (it enables the use of RXGB DDS compression for normalmaps): seta image_ignoreHighQuality "0" seta image_usePrecompressedTextures "1" seta image_useNormalCompression "2" seta image_useAllFormats "1" seta image_useCompression "1"

Ok, I confirmed it. Addnormals does not work with dds normalmaps for some reason.

You can't not have a far clip plane, this is a requirement for OpenGL rendering AFAIK. The reason is that the depth buffer contains numerical values which have to map from the near clip plane to the far clip plane in order for Z buffering to work correctly. It is up to the programmer to position the planes correctly so that the entire scene is enclosed but the Z buffer does not lose too much precision. I have no idea whether the OpenGL clip planes have anything to do with your problem though.

Yeah. Kids will be definitely time consuming. But this takes time. As long as they are small you have more time. Once they grow more up they also want to do what you are doing. But you definitely should devote as much time to them as possible. If you don't, then you will rue it later for various reason. And what is done can not be made undone, no matter how much you regrett it later.

The dock looks great! As for advice: The less you change from your current live, the better I think it is. If you live together for some time already, you will have developed an agreement anyway, so there is no reason to change it just because you are married now. It is definitely advisable to keep some free rom where each of you does his own thing, so you don't lock on each other without alternatives. Congratulations.

Yep, got it and I can see the problem. I'll see what I can do about it, I'm not sure what the reason for this is.

I'm once again diving through the libraries and once again I'm thinking about how this could be done better. Being well aware that this part of DarkRadiant is probably the most critical, I still think that there must be something that can be done to makes our lives easier. Orbweaver, do you think it's possible to make a slow transition with the old and a newly setup nodesystem side by side? Or would that be far too cumbersome and pose a serious performance drain? On a side note: Today I watched angua pasting a large part of her caves map into the bonehoard.map file. In the map there were about 3600 primitives and 550 entities. She selected only 300 of them and the system (2x 1.6 GHz) worked and worked for about 15 seconds before the new selection turned up. Maybe there was the renderer slowing down things as well, but this is not the only reason, I think. I had a look at the scenelib.h where the Instance class is defined and I think that there is some serious recursion going on. Each time the selection status of a BrushInstance is changed, it calls the selectedChanged() method from the base class. This checks for a parent and if a parent is found, it traverses the whole subgraph and this parent traverses the subgraph again - I haven't dug deeper. This is completely insane, rather than propagating the information from top to bottom through the hierarchy, the callbacks are pointing across the scene. What's your estimation on this? Is this another mammut-task like the dmap compilation stuff and should we rather leave it as it is?

Yeah, I didn't remove the class because I couldn't figure out its purpose and didn't want to break anything. If there is really a need for a container which retains insertion order but also ensures unique elements, this would need to be implemented using both a list (to retain order) and a map associating objects with their list position (to provide quick access to known elements). I suspect, however, that the only reason this class exists is because the developers couldn't be bothered to define an ordering over the Node objects, which is required for std::set presumably, and somehow didn't notice that their solution was going to be appallingly slow.

I haven't had a lot of DromEd experience. I've started dozens of maps, and never finished a single one, for this reason or that. Right now, i'm designing a rather ambition map (at least, by my standards) that in all likeliness will probably never see the light of day. But with some help, maybe it will. I want to create a rope that garrett can swing on. Nothing fancy like swining around a corner or anything. just running, and jumping and then swinging on a rope over a chasm of doom. does anyone know how this could be accomplished?