Search the Community

Well, two things: I was flicking throught the the nVidia website where it (somewhere) claimed that the 7900 supports a realtime global illumination solution (photon mapping or radiosity, it didn't eleborate on what kind of model they used or anything - the implication was that it rendered radiosity lightmaps in realtime in hardware though). Two, the tech demo from Crytec showed an editor view where a light was being moved around in real time, with shadows and diffuse ambient light consistent with some kind of real time global illumination model, and there has been numerous reports of next gen engines supporting real time global illumination of some sort on the horizon. Whether or not all of this is true or not I can't say, but the Crysis demo videos didn't look like any lighting model I've seen in a game yet, it looked like much higher quality lighting than in Doom 3 or any other currently available game engine. OpenGL 2.0 supports realtime radiosity in hardware BTW. Here are some links for you to consider: http://www.gamedev.net/reference/articles/article918.asp http://www.cs.unc.edu/~coombe/research/radiosity/ http://dee.cz/rri/ http://www.gamedev.net/community/forums/to...topic_id=381120

I am building a low-end/mid-range PC with a target price of $550. My goal is to build something that will be satisfactory for the time being, but substantially upgradable in the future. So far, I think I've done pretty well (much more credit to those on the steam forums and hardware IRC channels that have assisted me), but I'm trying to get as much input as possible. Therefore, if my fellow DarkModders would be so kind as to analyze the configuration I have below, your criticisms would be very welcome . MB: ASUS A8N5X Socket 939 NVIDIA nForce4 ATX AMD Motherboard - Retail $77 http://www.newegg.com/Product/Product.asp?...N82E16813131569 CPU: AMD Athlon 64 3000+ Venice 1GHz HT 512KB L2 Cache Socket 939 Processor - Retail $120 http://www.newegg.com/Product/Product.asp?...N82E16819103537 PSU: Antec TRUEPOWERII TPII-550 550W Power Supply - Retail $90 http://www.newegg.com/Product/Product.asp?...N82E16817103931 RAM: pqi TURBO 1GB (2 x 512MB) 184-Pin DDR SDRAM Dual Channel Kit System Memory - Retail $66.99 http://www.newegg.com/Product/Product.asp?...N82E16820141152 GFX: GIGABYTE GV-NX66T128D-SP Geforce 6600GT 128MB 128-bit GDDR3 PCI Express x16 Video Card - Retail $114.99 http://www.newegg.com/Product/Product.asp?...N82E16814125015 CASE: CHENMING 301KEB-0-0 Black Computer Case - Retail $35.50 http://www.newegg.com/Product/Product.asp?...N82E16811125450 HD: Western Digital Caviar SE WD400JD 40GB 7200 RPM 8MB Cache Serial ATA150 Hard Drive - OEM $49.00 http://www.newegg.com/Product/Product.asp?...N82E16822144173 (I know I don't have a CD/DVD drive selected...I'm hoping one might just "pop up" at one time or another...it could happen...) Total: $553 In addition, what are your opinions on cheap vs. expensive Power Supply Units? Do I really need to spend >70 to get a quality PSU? I'm seeing the same stats of $90 units on $50 units, but I'm warned that the $50 units are prone to die and kill your whole system. And then there are others that say the $50 units are perfectly fine--even for a person who plans on making a substantial upgrade in the future. One part of me wants to go for a $50 unit--in place of a $90, and spend the difference on a higher quality video card, and the other part of me wants to ensure stability and upgradability for the future. I'm torn to say the least.. Also, how much of a difference is there between CAS2 and CAS2.5 DDR ram? Thanks

Oops! Make that *Don* Ross ... I didn't have the book in front of me when I wrote the post and just did it by (bad) memory. http://www.amazon.com/gp/product/026218246...glance&n=283155 Thanks for your suggestions Max. The Ross book starts of distinguishing just what economics is the study of ... utility-optimization in the face of scarcity. I don't think it ever claimed to cover *all* behavioral patterns, but then again it also took pains to say that no particular behavioral patter could be a priori left out of the "machine" either, e.g., religious, artistic, political behavior, etc. So there you go. But I haven't got to the really interesting chapters at the end that talk about the actually links between econ and cogsci, so I'm anxious to know where he's going in that regard. I know right now he's focusing on just what "utility" really amounts to, what it is to "want" something that prompts you to action, and how the maximizing of satisfying that desire lets you choose among options, theoretical stuff like that. The Glumcher book "Neuroeconomics" looks at it in the reverse direction, how evolution actually "designed" neural-areas to be optimizing-machines, so the lessons of economics could actually be used to understanding the wiring, and uses the example of the (LIP) system which directs your eye muscles, that is, visual focus, what you want to look at, how you want to look at it, when, for how long, etc ... and the case is really pounded home that it uses a simple method of relative expected utility to weigh various "look at me!" options and choose among them, at least in part. And then it goes on to suggest that this sort of thing is a general feature in a lot of behavioral decisionmaking and should color how we look at these sorts of brain areas, at least for low level, more "reflex" like behaviors. The higher-level/more reflective decisionmaking you go, maybe the more things get complicated. This has got to be one of the more meandering threads ... anyway, I like it; sort of a grab-bag of what's interesting in the world right now. And it's not like you guys police OT so much in these "undisciplined" forums to stave off the overly-curious masses...

If there is no separate editor image, the editor tries to open the diffuse map, which is a dds. DarkRadiant can open dds images, but it might be that D3Ed has problems with it.

I'm still have some problems with textures pavement02 and 03 showing up in D3Ed. When I try to view them in-game they show up as solid black. They load up in DarkMod though. Here's the .mtr info. (pavement03.mtr is the same but with 03 instead of 02.) textures/darkmod/judith/pavement02 { diffusemap textures/darkmod/judith/pavement02 bumpmap textures/darkmod/judith/pavement02_local { if ( parm11 > 0 ) blend gl_dst_color, gl_one map _white.tga rgb 0.40 * parm11 } { if ( parm11 > 0 ) blend add map textures/darkmod/judith/pavement02 rgb 0.15 * parm11 } } Another thing is that I can't open the .dds files in the Compressinator program but I can open them in CrazyBump. ********** Ok...I think I just found out something. Apparently D3Ed has trouble with textures that are 1024x1024. I resized pavement02 to 512x512 in Photoshop and created a normalmap in Crazybump. I altered the normal in some way but what I did exactly. The left one is the original and the right one has been scaled down. I haven't resized pavement03 yet. ~Daniel

Napalm, if you really have been just hanging around waiting to hear what to do, why haven't you contributed to the recent discussions about the menus? The following issue in particular was directed right at you: If/when you're around, you need to speak up. Projects like this require continuous communication. The relevant thread: http://forums.thedarkmod.com/index.php?showtopic=3549

I just played around with it and ran into the same problems. In the player view code, a function named CheckAreaForPortalSky is called, which is located in the closed source area. Most probably they have the texture name hardcoded there, so we are stuck with the current name I suppose (unless we add a dirty hack... )

GnuGo is just a free version of computer Go that's probably the best for being free (like "GnuChess"). Just normal Go, no special rules. You need to (or should) play it with a front-end like JaGo. "Gnu" just means it's open source. It's like the Firefox of Go. The site wants to brag that "GNU Go has established itself as the leading non-commercial go program in the recent tournaments that it has taken part in ... most robots running GNU Go on one of the go servers achieve a rank of 8k-9k." I just got it because it was apparently the best program you could get for free. And I like supporting open source projects, I like the spirit of people tackling a massive problem together as a community, and just for its own sake, rather than as a commercial endeavor. Not too different from TDM. Oh, and I'm interested in reading their public discussions about the actual algorithms they use; it's one of those "big" problems in computer science. I followed the same thing for GnuChess because I was interested in reading about chess playing algorithms, so one led to the other. Re: Ranking systems, so you're saying a person gets ranked when they are involved in club playing. I see. I'm not sure if I'll do that any time soon ... I'm happy just playing casual games for now. Maybe if I find a club I'll try it for a while.

I just tried using Judiths 'pavement02' texture but got the same problems. Here's what the .mtr file says: textures/darkmod/judith/pavement02 { diffusemap textures/darkmod/judith/pavement02_D normalmap textures/darkmod/judith/pavement02_N { if ( parm11 > 0 ) blend gl_dst_color, gl_one map _white.tga rgb 0.40 * parm11 } { if ( parm11 > 0 ) blend add map textures/darkmod/judith/pavement02_D rgb 0.15 * parm11 } } ~Daniel

Yes, all the materials can be tweaked by hand if necessary to get an ideal frob. If there are a lot of materials with problems that might not be an ideal solution though. Did we ever solve the mystery of whether both blends were necessary for the frob?

In an attempt to get a handle on our animations, I've decided to create a list of all the animations currently applied to the citywatch model (and similar models). I've also given them a rating based on my opinion of their usefulness. Hopefully this will give our animations some sense of direction and help us keep track of what we've already got working. ** Currently ALL animations have problems with the hands--they are either twisted or dead-looking ** (This post is still WIP--just getting things posted, will organize later) -------------------------------------------- cough1 Description: An idle animation; guard coughs into hands. cower Description: A panic response; AI hunches over and hides face. death1 Description: AI teeters and falls backwards. Evaluation: death2 Description: AI teeters and falls forwards to the ground Evaluation: Needs to end earlier so ragdoll can take over, otherwise serious clipping into geometry could occur. draw Description: An AI draws a weapon from his left hip. failedKO Description: AI stumbles forward a step as if hit from behind. failedKO2 Description: AI stumbles forward a step as if hit from behind (mostly similar to previous). Ready For Use (good enough to be used as is) Passable But Needs Tweaking Not great, but good enough if there is no time to fix/replace them bow_fire Description: AI draws an arrow from their back, knocks, and fires. Evaluation: Movements are stiff. The arm holding the bow bends at the elbow, which it shouldn't. The animation is also very fast, and needs a delay between knocking and firing the bow.

I decided to take a look. For one thing a lot of the legs are positioned via coordinates (on the Bodies). They should work better if you use either the bone type of collision model (lower legs are used as "Joint 1" & "Joint 2" where you don't need coords) or use a shaped one (box, cone, cylinder) & specify the coords using "bone center" or "joint". Look at the guard_base or other AFs for a better idea. Also make sure the contained joints are set up properly. This can be confusing as hell. I never did get a true handle on AFs & I probably won't have the time but those are some of the problems I came across. Besides, you should be able to animate without an AF. The main problem with not being able to animate is your def file. You need to be more specific about the animation channels (under model horse_tame {) like: channel torso ( Body BodyFront etc.) //anything not related to the legs channel legs ( *RBackLegUp *LBackLegUp etc. ) Look at the tdm_ai_spider def file where I got really specific.

Hmm, looks like there's an image limit--I'll have to break this up. get_up Description: AI gets up from a sitting position. Evaluation: No problems. idle_drunk Description: AI standing idly, swaying back and forth. Unusable in Present State Not good enough to be used; needs to be redone or scrapped dance Description: The AI does 'the twist', slowly. Evaluation: Extremely stiff and unnatural looking, and kind of pointless...why do we need this? Recommend removal flip Description: AI does a jump into the air and flips around, slowly. Evaluation: Very stiff and unrealistic, and totally unnecessary--recommend removal

I'm working on that! After some modification of the side's angle I got a stage, where I couldn't walk on the grating but I could run onto it, so it looks like it's speed dependent. Anyway - this part of the ship will probably change, cause I'm going to carve a hole there, make grating a door, so it might act properly when grating is entity or I can flush it with the deck if it still causes problems.

I'm having hard time with some small adjustments exporting that model in game. At this moment it's one model but eventually it will be divided into props. But anyway - player has problems with walking onto some surfaces. He can't walk onto this one: (I lowered it down already and made sides at angles but didn't help) Next - stairs - player walks onto stairs with no problem but can't walk onto deck from stairs. This is the only exception: But he can't walk from stairs onto deck (when going upway, of course) in this situation in 90% of cases: and never in this case: I made stairs solid and flushed with deck but no change... I have tried diffrent things - moving stairs, flushing with deck floor etc... Of course jumping helps but that's not what I want... Any ideas? These heights seem to me too small to be a problem. What else is taken into account when computing player's collision under feet?

Has anyone tried this blackjack mod? http://www.elderscrolls.com/forums/index.p...howtopic=341499

In other words, there are problems. If they can be addressed and fixed, then great, we can add it as an option. Until then, it should be left out.

That's fine, too. Didn't realize people had problems with it. Works fine here (and looks quite good, aside from the limitations of using flat images for essentially 3D objects).

Sure, a half-assed hacked version isn't that difficult. But once you start looking at the bigger picture, it starts getting more complicated. Consider AI visibility. Suppose you were standing in front of an AI, in full brightness, with the AI facing you and very close. The AI would check the player's light level (lightgem is fully lit, so this test passes) and do a trace to the player's body (no obstacles, so this test passes), and send itself a large visual alert. Now suppose that you're standing in front of a portal, facing it, in full brightness, and through the portal you can see an AI facing you. The AI would check the player's light level (again, test passes) and do a trace to the player's body... Here's where we run into problems. The AI and the player are probably in different rooms. They might be waaaaay over on the other side of the map from each other. Where does the trace go? Way over the other side of the map, of course. So the trace would fail, even though from the player's POV they're looking straight at the AI. Sure, there are ways around this. You can figure out angles between connected portals and the player and the AI, and do traces from the appropriate points on the portal's surface in the appropriate directions. But it's pretty complicate and makes each trace several times more expensive (keep in mind you have to consider practically every set of connected portals in the whole map), and it's not what I'd call a trivial problem. Certainly not something you could do in scripting. There are doubtless more complications than that; tracing is just one off the top of my head.

The main idea behind the above design is to think of a SpacePartition as nothing more than a set that can iterate over intersections quickly... as such, there's no reason to make SpacePartition a singleton class. Whether or not everything is a Node isn't something I care about much... I just set up the example design that way because having a map which contains entities which contain primitives seemed like the simplest way to do things to me. Are we planning on handling anything drastically different from a Quake architecture? What did you have in mind? I was under the (mistaken?) impression that part of why we're redoing the scene graph was because DR had efficiency problems with intersecting large quantities of brushes. Could you point out which parts of the design had behavior that was too Doom3 specific?

I suspect that is a result of creating a CM out of brushes without applying the correct texture first (textures/common/collision IIRC). That may solve the collision issue, but it won't fix the lighting problems due to non-unit-length normal vectors. Whether this appears as a problem depends on the lighting situation and the model itself.

So, most of the basic questions about how to map are already answered. But what I want to know before I dive right in is this. How do the maps work in Doom 3 vs Thief 3? With thief 3 most of what you see is just static meshes, however this creates a big problem as those static meshes HAVE to be made in 3ds max (or at least need to be converted to 3ds max and then exported from 3dsmax as a .tim file). This is to say of course until someone comes up with a converter or a python script for blender that would allow you to export direct from Blender as a .tim file. Does Doom 3/DM work on the same principal of static meshes? If so, what are the file types? Do I need to get a specific program to make them? Am I still just as limited as I was before with thief 3 or am I given more wiggle room? Pretty much I want to know what its going to be like in there. Am I going to spend most of my time bsping or building stuff in Blender and exporting it? In thief I spent something like 15 hours setting up the BSP in the level and hindsight being what it is I realized I could have cut that down considerably. However I've spent much more time OUTSIDE of the editor working on creating meshes and making custom textures for them etc. Am I going to find a similar method of working if I switch over to doom3/dm? I don't prefer either method over the other per se. Although using Static Meshes really does make the level look much nicer. Really more than anything I want to keep blender cause I know how to use it fairly well and I'm comfortable with it, so I need to know what file types I'm going to be dealing with for objects and meshes (if doom uses them). Cause if I'm stuck using 3ds max still then its not worth it for me to even bother. Edit: I did forget one last question. I noticed that you could start mapping just using Doom 3's built in editor. So I assume that the conversion between dark radiant and normal radiant will be simple enough. What are the advantages disadvantages to making things this way? Are there problems that have already started cropping up as far as making things in radiant and then importing them into dark radiant goes?

Two problems: How do I change the moon in the tdm_starry_sky_prefab? I wanted to use a full moon instead, but I can't find the place where the moon texture is. Second: The moon image is actually wrong. The shadow on the moon can only stem from a earth shadow on a full moon during a partial/full eclipse. Compare: (the latter from: http://www.raumfahrer.net/forum/cgi-bin/Ya...m=1156586714/45 ) The "shadow" on a normal moon is actually the selfshadow of the moon, e.g. the bright part is lit up by the sun. And coming from one side only, the sun can't light up much more than half of the moon as the other side will always be in the shadow of the moon itself (it is a sphere afterall So the one we currently have has an impossible shadow on it. Unless of course, you want to simulate an eclipse - but since these eclipses happen so fast in real-life, this isn't a good idea as the same moon image will be shown during the hours of the map

Yes, they probably know about us. And if they woul dhave problems with us, they would have told us by now, I would imagine. I really don't understand this fear, because we are NOT doing any illegal. Really! The media creates so much hype that people constantly turn their head, because they try to tell you that everything is illegal that you haven't paid Big Corporation for.

Support from Id, would definitely be appreciated. Getting payed for it would cause a lot of problems though.