Josh

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.

They stream textures and shaders in. That's why textures start blurry and get sharper as they are loaded. I don't like requests like this because people are requesting things they can't even define.

Dynamic loading like you describe is unlikely to happen. It would only benefit a few people with a design so ambitious it is unlikely to ever be completed. Even STALKER and Crysis don't use this approach. This would also limit the flexibility of the engine. For example, right now you can loop through all the entities in a scene. What happens when you have other sections of a scene loading and being freed? An entity you have a handle to might no longer exist. A raycast you perform might go outside of the loaded area of the scene. And if people aren't even filling up the existing area they have now with a scene they make, why would they need more space?

It will come.

The animation state between instances are not related, so I don't see any problems here.

It's already supported. Uncomment line 343 of shaders\lighting\pointlight.frag: //ambient = gl_LightSource[0].diffuse * (1.0-falloff) * 0.25 * diffuse;

https://www.paypal.com/xclick/business=orders%40leadwerks.com&item_name=Leadwerks%20Engine%202.3%20single-user%20Upgrade&amount=50.00&no_shipping=0&no_note=1&currency_code=USD I am not sure why you need to register an account. You should be able to do just a plain credit card transaction with PayPal.

The state approach makes sense to me. I don't know how else you would do it.

It will be by Friday next week. I have some real-life stuff going on right now that is taking a lot of time this week, but it ends next week. I think mostly beta testers didn't want to start messing with beta script implementations, and my presentation of it was not very good during testing.

mesh1:AddForceAtPoint(TFormVector(Vec3(0,Force,0),null,mesh1),TFormPoint(Vec3(0,0,2),null,mesh1)) 1. You can't add forces to a mesh, only a body or a model. 2. Is Force a float value or a Vec3 itself? 3. In Lua you use nil, not null. 4. AddForceAtPoint is global, so I am not sure why you are transforming the point and force to local space to begin with.

The Newton module has to be edited to support Linux/MacOS, and the OpenAL binding needs some small changes, but other than that everything should compile and run the same on all platforms.

It is possible there could be a problem with NVidia SM3 cards. It seems unlikely, but that's the only possibility I can think of. Will test.

Just make a quad and angle it to face the camera.

LoadScene?

SendMessage will remain in place to make sure existing code is supported. However, I think in three months no one will ever use it. It's easier just to do what you want to do to the lua table.

Fascinating how good it looks. Maybe some muzzle flash would perfect it? I notice in STALKER the pistol has a faint heat haze effect, but I don't think that is too important.

That is why I am doing this now and not later. I didn't get much feedback on Lua in the beta phase. There was very little interest in it, actually. I had the choice to make between a simpler less powerful system that was a nice toy, or a more powerful system that was less forgiving. I chose the first. Then when it was released it became apparent that lots of people were very serious about using it, so I quickly decided a single state system was more appropriate. It's not the way I would have chosen to make decisions, but as soon as it became apparent it was better to do it before anyone had committed any code. I probably do more trial and error than some other engines I have seen, but I also think we come up with better designs in the end. The Lua stuff is very new, so I would not look to it for stability right now. The main engine API has been quite stable for the last 6 months or so, and I don't see any changes happening there. Onwards!

This is the first of many LULZ!