Josh

I meant a heightfield where there is just a pointer to the height data that can be changed at any time. PhysX heightfields can't be dynamically updated: http://developer.nvi...?showtopic=3548

You should talk to the guy I had make the soldier model.

If anyone wants to make a desk like below, I will add a script to give it physics. The drawers should be separate pieces. A physics shape needs to be created for the desk and each size drawer you use. Each drawer can be a limb in the mesh file, with a name like drawer1, drawer2, etc. The pivot of the drawer should be in the center rear of the drawer. The drawer physics shape should consider this point the origin...the draw physics shape will be loaded from the .phy file and connected at this point with a slider joint, with limits. After I write the script, you will be able to grab the drawers in the editor and pull them open to see what is inside. It might be easier to just make all the drawers the same, since it will probably be a little confusing to set up at first. This is what got me thinking about this: http://www.youtube.com/watch?v=Ux4OwkS9ybA

That's not feasible because each physics library is so different. PhysX does not support heightfield data. A terrain has to be made out of a mesh, and editing the terrain in real-time like we do is not possible. So what is everything considered "disabling physics"? Generation of the .phy files? What about raycasts? They use the physics system. Should they be disabled? What should happen if the user calls a raycast command when physics are disabled?

I think it's very useful for debugging and adjusting the engine for individual needs, but it does require a fair bit of courage. Now that the engine has Lua and is pretty stable I think it's safe to branch off with your own version of the source.

The only time I have seen this occur is when a really detailed collision shape was used with lots of small triangles, and it was a situation that should not have been allowed to happen.

You can also compile files into your EXE, with some languages.

The most I have seen is some boxes falling. I have not seen: -Selective collision system. -Interpolated physics with constant update speed. -Joints -Vehicles -Terrain -Character controllers -Any of the features that motivate people to look at PhysX in the first place. So the most I have seen is some experimental stuff that doesn't have nearly the same feature set as our current implementation. I'm not sure what the motivation is to pursue these alternatives.

Well, we know something is funny in your code. What kind of a rendering setup are you using? Framework, or something of your own? Have you customized the renderer or done anything that could affect the depth buffer?

Enable z-sorting in the material.

That's strange. Maybe the entity view distance is set to a low number?

Here are some of my thoughts on how a future engine might look. I am not devoting any time to this, and it would not come to exist for several years, but it's fun to think about technology and design: I've been fascinated with the game "Fuel". This game has an enormous playable area that is streamed from the hard drive. You can drive for hours and barely cover a fraction of the map. For some reason the game has been given bad reviews. I played Motorstorm on the PS3, and I think Fuel is a lot better than that game, not even considering the impressive technical features. Anyways, I love the large open world. Fully dynamic lighting was one holy grail of game development, and I think a continuous open world is another. I would start this with a concept of "regions". Each region is a square on the grid, perhaps 1024x1024 units. The region has a terrain heightmap, terrain normal map, and an SBX file for all entities in the region. As you move around the world, regions are loaded from the hard drive in a square of playable area around you. Maybe there are 16 regions active at any given time. This number should be adjustable. Only physics and scripts of the entities within this active region are updated. When a region goes out of the playable area, it is saved to a file, and this new file is loaded if that region re-enters the playable area. So you aren't going to have enemies fighting and moving around when they are a million miles away. The engine just updates the regions nearby, because it would be simply impossible to update millions of entities. The AI in STALKER actually uses a technique similar to this, and I think they originally were planning on a huge continuous world but weren't able to pull it off. Each region can be culled on a separate thread, so this design lends itself to multithreading. So far what I have described is a big challenge, but it seems feasible. The real nightmare begins when we talk about networking. If your friend walks ten miles away and interacts with a person who's attitude towards you changes based on the interaction, well the server needs to be running two simulations. One simulation is for you and everything around you. The other simulation is for your friend and everything around them. What your friend does will change the world outside your playable area, so that when you enter that region it will be different than when you left. Now consider physics. Due to the massive distances, there would need to be two separate physics simulations running. Then they would need to be merged together when you approached each other. Wow, no wonder no one has done this yet! Fuel has a multiplayer mode, but it's just a racing game. Your actions don't have any permanent consequences on the world around you. An FPS, adventure, or RPG game will be quite different. I'm not even sure this is technically possible, without severe restrictions in flexibility. Fortunately, real-time rendering is not going to change much in the next ten years. We'll be able to do more as hardware advances, but I think we'll still be using the same basic techniques for a long time. That means that every feature and technique we add now will still be useful for a long time, even in a new engine.

Transform the point from local to global space.

If you want an AABB you can also make a mesh that represents that shape. If we had a model-less entity you drag into the scene, it creates some design problems. Let's say the entity is an emitter. Where does the class script come from? Does script support have to be added to the base entity class, instead of just the model? If so, how does the script delete whatever entity it starts with, and replace it with an emitter, using the same script? What if the emitter is deleted and recreated, as happens when the particle count changes?

I don't see much point in this because the attempts at implementing other physics libraries have not gone very far.

No, it's not, but alpha masking with antialias doesn't have any of the z-order issues alpha blending has. I think alpha blending was more appropriate when texture resolutions were lower. With higher resolution textures I don't think alpha-blending of leaves and things like that is as useful.

Because in LE a model is the only scripted entity, so a model and a script allow you to create any kind of object you want. Particle emitters, lights, roads, etc., can all be implemented using this convention. If you want to get rid of the extra model when your game loads it, this is pretty simple to do. It shouldn't make any difference though, since the model is invisible and normally will have no collision set. If you want to make the model so it isn't even pickable, replace it with a GMF file that has no surfaces...then you would only be able to select the object by clicking on its node in the objects tree in the side panel.

All orders are processed. Thank you.

This thread is marred. Feel free to try again in a more polite manner.

If you just save the script every instance in the scene will be freed (with the old script) and reloaded (with the new script). You should not run a class script.

Probably not.

The reason these entities are linked to a model is because a model has a script, and can be moved around and deleted again. This allows you to make lights, particle emitters, or anything else in script, and the editor doesn't have to have everything hard-coded. If you want to get rid of the model component in your own game loading routine, you can just modify the script to remove the model when your game loads the scene. Something like this: if MyGameIsRunning==1 then object.light:SetParent(nil,1) object.light=nil object.model:Free() end

This indicates the modelreference value equals nil.

See attached. Arial9.zip

Add a call to GCCollect() in your main loop. I don't recommend using the auto GC mode because it is possible for it to cause crashes. The problem is object Delete() methods might be called at any time, and in the case of OpenGL or Newton objects, it might cause the program to delete these things during a sensitive routine when they are being used. It might do something like delete an OpenGL buffer while another buffer is being set, and it is possible this might cause a crash in some situations. In the future I will add the deleted objects to a queue to be deleted during the UpdateWorld() routine, so they will be more safe in auto GC mode, instead of deleting them in the Object Delete() method.