Xycaleth

Should be able to. q3map2 doesn't do anything with them, it's all done by the renderer.

It will be totally modern graphics

This is still a long way off anything in CoD and especially BF3. BF3 has some pretty insane stuff in it.

I guess I can post what I did to get the specular and cube maps working before I disappear unexpectedly again. For cubemaps, you simply place a "misc_cubemap" entity where you want the cube map to be generated. All rendered surfaces use the cubemap that is closest to them. You need to enable it in-game using r_cubeMapping 1. For specular, this is the shader I've been using: textures/rend2/spec25 { qer_editorimage textures/bespin/newfloor { map $lightmap } { stage diffuseMap map textures/bespin/newfloor blendFunc GL_DST_COLOR GL_ZERO } { stage specularMap map textures/bespin/newfloor_s specularReflectance 0.25 // default is 0.04 - non-metallic surface specularExponent 8192 // default is 512 } }The main thing to notice here is the use of 'specularReflectance'. The value here describes the material's refractive index, i.e. how much light is reflected or refracted. For non-metal materials, the default is good. For other types of material, you can look up the refractive index from http://refractiveindex.info. You can also control how much specular specific parts of a texture has by making use of the alpha channel. The value in the alpha channel then gets multiplied by the 'specularExponent' to give the overall shininess of the texture. As you can see from the video, the shininess also makes use of the cube map, so the shinier something is (and the more reflective it becomes), the more visible the reflected scene becomes.

All will be explained soon I just need to make sure it's all actually working properly lol.

So, I'm ignoring the lightmap problem for now cause that's blocking me from looking at other things. Just had a look at testing specular for map textures and it seems to work fine. You can also see it using the environment cube maps. Here's a short video. https://www.youtube.com/watch?v=LKu3Oxi6nBo From left to right, each sphere has an increasing specularity until it becomes really shiny in the last sphere. The first sphere has no specularity, and only diffuse. I'll release the test map with all the assets at some point so you can see how it's done

Down the road, I plan to greatly simplify the .mtr shader syntax anyway So you'll need to write two separate shaders.

If you have a .mtr file present, it will ignore the .shader file. Or do you mean, it doesn't work at all without a .mtr file?

But that would require knowing when the collision was going to happen. And then you'd have to predict and... yeah, back to square one.

Sorry for the lack of updates everyone. I'm finding it hard to motivate myself at the moment but I'll get back to it soon hopefully - don't worry!

Huh, didn't know that! The code confirms what you've found as well. I think the .shader should be optional to be honest, so I might look at changing that.

rend2 treats .mtr and .shader files in the same way - you can use all the new keywords in either. The only difference is, like DT said, that priority is given to the .mtr files. The benefit of using the .mtr file is so you can use the .shader file for the vanilla renderer and not have any errors.

While the talk does present some interesting ways of hiding latency, the previously mentioned problems still stand. All the examples shown in the talk all have a fully predictable component to them. The grenade has a fixed animation length before the grenade is thrown. The armour lock is the same. The synchronized animation for assassinations works more by coincidence than by design as you can adjust the player's perception of what's happening. Compare that to two sabers colliding. What part of the collision, or the few milliseconds leading up to the collision, are predictable? There are none. If the client predicts it wrong, because the other player has suddenly turned violently or a weapon projectile caused you to deflect it, then you get horrible visual feedback.

ZeroPing for guns works because their projectiles have a very predictable path through the world. They travel in a straight line or arc and cannot deviate from that path. With sabers, the player can change the path of the saber at any time and in any direction during the swing which isn't something that can be predicted. The only way this would work is if you were playing single player or in a LAN game where your ping is zero anyway

Did you tell it to use the rend2 renderer? Enter /cl_renderer rd-rend2 into the console and then /vid_restart.

There isn't an SP version of rend2 for now. It's multiplayer only until I get everything working and fixed.

To the modelers out there, this news maybe of interest to you. Autodesk are discontinuing its Softimage modeling software after its next release in the month to come: http://area.autodesk.com/softimagetransition

The force sun stuff is mainly for debugging purposes. There's a way to do the same thing using sky lights but I can't remember how.

Try turning off texture compression? Should be an option in the regular video menu.

I think DT mentioned it was broken a few pages back. Unfortunately I'm still not feeling great and so no more changes to report this week

That does look odd. What does your shader look like, and what does the normal map look like?

Which shadows are you referring to? Can you post a screenshot please?

This will happen if you are not forwarding the ports on your router. Take a look at this: http://portforward.com/english/routers/port_forwarding/ You want to forward internal port 29070 to external port 29070 using UDP.

For Visual Studio 2010, you need to install the VS2010 service pack 1.

Dat parallax mapping