Gildoran

My guess would be the fact that you're guaranteed games will run on it without hardware problems, and they're more accessible to people who don't know how to use computers. Also, console games seem to have fewer bugs than PC ones. (or at least that used to be the case)

As far as I know, we aren't going to have any MP support, and we'll only start on the campaign after the first release of TDM. Anyway, most people working on TDM are big fans of providing multiple entrances to buildings, multiple ways to solve stuff, etc. Personally, I'm not sure I understand why you think T2 was more maze-like than T1. Were "Shipping and Receiving", "First City Bank and Trust" or "Kidnap" like a maze?

@Obscurus: My point is that you're arbitrarily assuming that having "planet" describe the size/shape of something is superior to describing its behavior. There's nothing inherently wrong with choosing a definition of "planet" such that Earth would no longer be a planet if it were ejected from the solar system, just as there's nothing inherently wrong with choosing a definition of "moon" such that Luna would no longer be a moon if it didn't orbit a planet. You seem to have your own predefined view about what it means or doesn't mean to be a planet, and you're religiously arguing that it's better than other, entirely different definitions. It seems no different than people who like to argue Europa can't be a planet because in their predefined view, one planet cannot orbit another.

What about once the source-code is released for free? If we can make sure that TDM doesn't use D3 assets, then we could release a version of TDM that's entirely free. Imagine how great it would be for the community if all people had to do was download TDM. I don't think the hell brick texture is worth giving up the possibility of an entirely free TDM.

While I agree with you that the definition of "planet" shouldn't be based on orbit, I think you may have missed my point: If you don't have a problem with the definition of "satellite" taking into account orbit, how can you argue that there's something wrong with the definition of "planet" taking into account orbit? Although I don't care for this definition, I don't see anything "wrong" with defining a planet as a satellite in stable orbit around a star, with enough mass to be spherical due to gravity.

Keep in mind that if we use D3 assets, we force people to buy D3 in order to play TDM.

While I agree with the idea of calling anything with enough mass to be spheroid a planet, I don't see why orbits and behavior and such can't be taken into account for scientific terminology; how else do you define a "moon" or "satellite"? (surely those are useful scientific terms) And I don't see anything wrong with taking into account the material something is made of, the way terms like "gas giant" do.

Back when textures were just tilable images, this would have made more sense... but the tricky thing about doing it now is different engines require different inputs for textures... I've heard that assets designed for D3 may require a lot of work to convert them to run on other engines and vice versa... so that can make it kind of hard to make a general purpose texture pack if it has to be targeted towards one specific engine.

It seems like the "natural" button in the texturing window doesn't do anything. Is there any chance it would be possible to have an option to draw the x/y vectors of the texture space, like "r_showTextureVectors 1"? (so I know which way to scale, and which way the texture is facing on ambiguous images) Thanks!

Are you sure the affect of multiple bounces would be so bad on performance? I mean you wouldn't have to apply the matrix multiple times: you could precompute (interaction matrix)^n, and use that exactly as if it were (interaction matrix)^1. How does one handle portable objects if you do patches? The reason I was thinking concave spaces was because I figured something like that would make it possible to handle portable stuff, and light them the same way as level geometry.

What about things like support beams? The example I gave above of trying to texture a 40x40x256 block was intended to illustrate that having combined textures makes it difficult to texture things like that. What happens when the mapper needs to fit one of the engraved patterns at the top of the texture (in previous screenshots) to an arbitrarily sized block? What happens when you want to texture a simple, yet arbitrarily long pipe with one of your metal gen textures and you don't want any texture seams? It's those limits that bother me. But those weren't created with the intention of being used to texture arbitrary things. I'd be fine with the materials used for models being combined textures, but for maps combined textures are very inconvenient.

I just saw the realtime radiosity video for the new Crysis engine, and I was wondering if anybody had any ideas for how they might have implemented it, or how you might implement your own realtime radiosity. My current best guess is as follows, though it has severe problems: There's some kind of extremely low-poly radiosity world. When the map is compiled, the low-poly radiosity world is also compiled too, into a BSP containing convex areas, ala Quake1-style compilation. Then much like how Quake engines calculate radiosity, a lighting interaction matrix would be created for this low-poly geometry. However, instead the light sample points being a grid on each surface, they'd only be on the vertices of the radiosity world, making the matrix much smaller and easier to compute. Then, instead of applying the matrix right away, it'd be saved for later. To calculate lighting, you'd do the following: First render the direct lighting pass similarly to how you'd render in D3. Then you render the radiosity as follows: on the CPU, calculate how the lights hit each of the vertices of the radiosity world, only allowing for direct hits. (you'd probably do a trace from the light to each of the vertices in PVS for that light, and if it's not obscured by a face in the radiosity world, light that vertex; this probably wouldn't be prohibitively expensive, since the radiosity world is EXTREMELY low-poly.) Then after you have the vertices directly lit by all the lights, apply the interaction matrix to obtain the radiosity. Then to light the rendered world on the GPU, for each pixel you find out what area it's in, and interpolate the lighting from that of the vertices of the area the pixel is in. Advantages: Doors and moving objects could influence the radiosity by blocking traces that occur when the radiosity world is directly lit. Disadvantages: There may be sudden changes in radiosity as a moving light hits new vertices. Also, I don't know how feasible it would be to run a BSP search and interpolate lighting for each pixel on screen. (I'm guessing it might not be possible for pixel shaders to do, but I imagine such a thing would need to be done on the graphics card, which makes me think this method wouldn't work)

Although I've never played it, wasn't Natural Selection a combination of RTS and FPS? You had a commander who ordered the players around the map...

I didn't know that... I'll have to try it out some time. Thanks for mentioning it!

I'm the opposite... I'm a math major but I have a complete phobia of modeling. All the modeling software I've ever seen was overly complicated, and the tutorials had all sorts of useless fluff that I didn't care about, like rendering, and didn't seem to cover the stuff I actually needed to know. Being able to make the shapes you want is completely useless if you can't export them. I wish there was a tutorial on how to create and texture a cube, then get it into the game.

I usually prefer things to be selected and moved as a unit, but there are times when I wished I could have edited the brushes of an entity without having to convert to worldspawn and back, losing spawnargs along the way. It'd be great if there was an option to turn on the independant brush code.

I mean the orign is what D3 rotates the entity around. If a script tells an object to start rotating, it rotates around its origin. If you set an angle in the spawnargs, the entity gets rotated by that angle around its origin upon being spawned, and shows up that way in D3ed. If DarkRadiant always has the origin at 0, I imagine things like darkmod doors wouldn't work. This is also why it's important for the user to be able to easily see/edit the origin graphically in addition to typing in numbers: it makes it easier to place the axis of rotation for darkmod doors, or the focus for readables.

It is neccesary. The origin is what the entity rotates around, for one thing.

After looking at it, I still think that having the trim/etc all in a single texture is likely a bad idea, because it's very inconvenient for mappers. Admittedly, having it all in a single texture may be better for performance due to fewer draw calls and potentially fewer triangles, but I'm not sure that outweights the difficulting of using textures with multiple parts in a single image. To see what I mean, try making a map with a single 40x40x256 beam that has the horizontal trim (the one seperating the main texture from the blocks/patterns) fit to all sides.

I'm sorry about being mostly away the past few days... I'll get to it today. I do agree that it would be bad to tailor each gen skin for each model, and that we should just have gen skins that don't fit with any one model.

Er... wouldn't that be qualified as a hermaphrodite rather than asexual? Unless cutting Sparhawk in half leads to two Sparhawks... hmm, twice the programming power!

Er... I'm not trying to make a point about whether or not motorcycles are safe. It just bugs me when I see statistics that sound convincing but are completely meaningless. It's like quoting the murder rate for a city in raw numbers rather than per-capita.

Assuming that you're refering to the US, what about the reason behind the second amendment? (that people should be allowed to posses the types of weapons neccessary to overthrow their own government, as a stopgap against totalitarianism) Mind you, I've never owned or handled a gun, and I'm for gun-safety laws, but at the same time I do think people have a right to guns.

To me, that statistic appears meaningless unless I know what percentage of riders recieve formal training. For example, if 95% of all riders have no formal training, then that statistic would suggest that the training does more harm than good. If 90% of all riders have no formal training, then the formal training has no effect. If 80% of riders have no formal training, then the formal training has only a very slight effect. If only 25% of riders have no formal training, then the training has a significant effect. Etc... I'd be very interested in knowing what percentage of riders have formal training.

Anyway, don't hold off uploading PK4 until the end... things are easier on me if I just have to upload a few textures at a time. Also, if you can send me a single set of textures that matches your plans, we can discuss any problems I might have before you do a hundred of them.