Josh

New update Thursday, if everything goes well. Progress will speed back up after that.

Newton is far more stable than PhysX, ODE, Havok, etc., because it is based on real physics equations and does not cut corners. I also have a good link to the developer, and have gotten a few features implemented specially. For example, PhysX does not have any kind of dynamic heightfield body, so our dynamic terrain and editor would be impossible with it.

GetMeshModel() is not an engine command. It just goes through parents until a model entity is found.

"Larrabee will not be a consumer product."

Yes. You'd even be better off with an 8800 over a 9600. Basically, any NVidia card where the second number is less than 8 is a budget card: GEForce 9600, 8400, 240. They just keep repackaging the same slow cards and selling them for cheaper under a new name. The real cards are like 7950, 8800, 9800, 280, 295, etc. I know, it's a terrible naming scheme. Confusing the customer so they don't even know which one is faster is not a good way to sell hardware.

Any GEForce 8800 or GEForce 9800.

Just uncheck the "cast shadows" box in the properties.

http://www.nvidia.co..._9600gt_us.html 64 stream processors, so not bad but not great. If your shadow maps are that low res you might as well disable shadows for those point lights. Additionally, the optimization technique I am talking about will lower the amount of geometry that has to be redrawn when shadows are updated. It will result in a very big improvement in this scene.

Specs? There are still some additional shadow techniques I can use to optimize it further without losing quality. They'll probably be in place before you have a demo out.

Don't bother, it will be officially supported in a few days.

http://www.bit-tech.net/news/hardware/2009/12/07/intel-larrabee-cancelled/1 I called this one a while ago: http://www.3d-test.c...leadwerks_1.htm And more recently here: http://leadwerks.blo...cuda-fails.html

We should do a really bad idiot-box style video. I TOLD YOU, IT'S A FEATURE! NOT A BUG!

As a general thing, I recommend against Win7-64 unless you need that extra RAM for some reason. I am running Win7 64-bit and the only benefit I get are two "Program Files" folders and EFax and a bunch of other programs won't run. This is the third 64-bit OS and it still hasn't caught on.

Maybe LE3 will be designed that way from the start, but that's a long ways off. I do kind of like the idea.

You should write a script and have various people on the forum voice it.

I agree.

Very nice skies, thank you.

It's not that hard to make, but the problem is it would make the engine into a different kind of engine. One that was highly specialized and more restrictive. Most people would not like the changes. It's also a deep-down fundamental design issue, and I am not going to scrap everything now.

Check my gallery pics. I already implemented a raytracing approach that is probably similar to what they did. It's just not quite ready yet.

I do like the idea of an infinite world, but if I were designing such a system... -I wouldn't allow mesh modification. -There would be a stricter "model" class. It would not be possible to make changes to the mesh hierarchy after loading a model. -The engine would differentiate between static and dynamic objects. Static objects that are part of the scene would be be alterable in any way. -It is likely scenes would require some kind of baking/pre-compiling step. So it would really be an entirely different project. You might not realize how different the design would be, but to me it is like you are saying I should start over from scratch.

No. I don't have much time right now but at the end of next week will be back to normal.

An engine like FC2 has to be designed that way from the very start. The problem is a lot of compromises have to be made for it to work. What happens if you modify a mesh, and then it goes out of the playable region? Then when it is reloaded, the mesh is unmodified? What about scripted entities? When they go out of the region and then come back in, all Lua data will be lost? So the user will have to have a save function to save any important info about the lua state so it can be saved across transitions. There are so many complications this would add that most users would be very frustrated by it.

It isn't possible due to the reasons I said above. Is it worth losing the grass system for? "Streaming" can mean a lot of things. In Crysis it means textures are loaded in one mipmap at a time. In Far Cry 2 it means the whole world is one seamless region. The kind of streaming Crysis has is not the same kind of streaming FC2 has.

There would be so many workarounds and complications you would have to deal with when programming that people would be yelling to change it back if I did this. What happens if the user does this?: mesh=LoadMesh() CountChildren(mesh)//mesh is not loaded yet. Should it wait? Should it crash? Should it only return the loaded children? Now let's say your program loops through all meshes in the scene and does something. After it finishes, a mesh that was loading appears! Now you can't figure out why that one mesh was unaffected by what you just did. Your entity counts would change during other routines which could easily cause random crashes if you are not careful with your code. It's hard enough now to keep everything in order and bug free. This would continuously introduce a lot of new bugs in my code, and in your own games. There's a thread on the Unreal forum where a person who is familiar with LE asks how to alter a mesh's vertices at runtime. The answer was that you could not with that engine. That's just one example of the tradeoffs of freedom this kind of thing involves. If I allow multiple terrains, then all terrain shaders like grass color, vegetation height, or vehicle dust color are broken.

1. The editor doesn't make instances in the way you are thinking. 2. Materials can be self-illuminating like a tv screen, but they don't cast light on other objects. I have not experienced the last thing you described.