Rick

Pickinfo.position not Pickinfo.entity.position

See I knew before that picking is on the geometry and not the physics shape!

PostRender should only be used for drawing. UpdateWorld() is where you should be checking for mouse stuff. Also, you will have lots of variables with this stuff. You are starting to see why organization becomes important and why you now need to start breaking your controls into their own class that handles these things.

@NA Good point.

@NA Wouldn't this almost be just as much about memory usage as it is speed? Not having to load 3 models of everything does save your on memory. @tournamentdan Nice on the walls idea. It then would come down to getting the interior mapped out to the exterior to match up and look good and being able to populate the house correctly in editor, and physics.

This would be a little misleading because people will think LE controller when you say that, but the LE controller can't angle like that. You, being more advanced than most, I'm sure meant non LE controller. @OP You should get able to get the angle of the normal and that should be the angle to rotate. If you think of a normal pointing straight up, then you think of your terrain's normal (possibly pointing out, the angle between those 2 would be how much to rotate.

It is actually very easy. self.entity:SetInput(blah, blah, blah); self.camera:SetPosition(self.entity:GetPosition()) self.camera:SetRotation(Vec3(45, 0, 0)) self.camera:Move(Vec3(0, 3, 2)) Just play around with the Move() values to get the distance right, and the rotation value to get it pointing at the character right. If you want to add rotation around with the mouse it gets a little more involved.

Video says it's private. I don't think you can. In 3rd person you are generally following something (character). So you still need a character controller. What you do then is set the position to the controllers position, and then use Move() on the camera to offset up back from the character. Then you rotate your camera to look down (or do a point at function to point at the character).

Use the normal entity character controller and set the camera's position (x/z anyway) to the controllers after you call SetInput(). Then take the controllers y position and add an offset because otherwise it'll be at ground level which is probably what you don't want. This is basically what a FPS game does. The player moves around a controller and the camera just gets set to the controllers position with a y offset.

np, I hope it's that easy . This gives you the added benefit of capturing the mouse down event so you can switch your button states to show that as well. so you got that going for you now I always like buttons that allow me to press down but then move off if I change my mind at the last minute.

Are you using MouseHit()? XXHit() functions only fire once a frame so if you have other Hit()'s in other scripts for the same keys/mouse they won't register on that same frame. The first one to get called wins (at least I remember this being the case) Be sure you are using MouseDown() with booleans to keep track in each script to avoid this issue. if MouseDown(1) == true and leftMouseDown == false then -- do mouse down stuff here leftMouseDown = true elseif MouseDown(1) == false and leftMouseDown == true then -- do mouse up/click stuff here leftMouseDown = false end I'm at work and it won't let me get to your link to your code so just wanted to point that out that I remember having issues with this on later versions of LE so I'm guessing 3.1 is the same.

You seem to be talking about multiple cubes then? I mean you'd have the kitchen, living room, bedrooms, bathrooms, etc all in different configurations to make the house unique. This seems to be a pretty extreme view of tessellation usage. Sounds sort of like the round peg in square hole sort of thing. I just don't think this is what it excels at. I get the idea and excitement but I'd be shocked to see anything like this made from tessellation.

Could you really have 1 cube for inside the house? I mean we are talking the inside of a house here. Can tessellation really make all the different kinds of rooms needed in a house from 1 cube and a texture map? I'm guessing no on that so the inside cube would be your normal model of the inside of a house which would be way more than 22 triangles. So now we are talking savings on the outside of the house only, which true there is savings on that part, I agree. How are physics handled with tessellated objects?

There is different kinds of detail though. There is how many polys on a model (which tessellation handles very well), then there are completely different models needed (like in the house example). Your suggestion seems to use a combination of traditional LODish (1 model for house outside and 1 for the inside only showing the inside when the camera is close) and tesselation (on the house outside). I think the suggestion is worth checking out, but this idea related to the house is more than to increase/decrease poly count. It's to show an entirely different model or not given camera distance as well as increase/decrease the outside model.

@tournamentdan How much different is what you describe than LOD? I get you can have the inside and outside of the house be 2 different models (I think when you get into windows and such a risk might happen with seeing the "nothing" inside the house (normally your windows would just be solid when far away, and transparent in the slower model)), but we're still left with doing camera distance checks to show the inside of the house model. That's the same concept as LOD. Sure you aren't loading an entirely new model, but you are still loading 2 models for the same object (outside/inside). To me a combination could work. Tesselation on the outer box, and when in range show the inner house. However, I have to wonder how creating the inner house would work knowing that the tesselation could morph the outer box to cause issues with the inner model. One would have to know what the final close outer house would be tesselated to accurately design the inside, or lots of trial and error. With this I mean possible outer walls clipping into the inner model. I guess my point was that tesselation isn't going to make the inside of the house so you'll still need multiple models to represent the house in a distance check fashion, which is very similar to the LOD concept anyway.

On the pressure plate attach a script. In this script you'll probably want to make a script parameter that is an entity, that is the target pressure plate on where to send the character. Go into the Script:Collision(). Check if the entity passed in is type or name player by using: entity:GetKeyValue("name") (this is the name your player object is in the scene tab. If it's the player then you can get the position of the player with: local pos = entity:GetPosition() Then you can get the position/rotation of the pressure plate with self.entity:GetPosition() in the collision function. Now you have both positions and can tell where the player is in comparison to the plate. Now move the player to the destination plate that is your script variable. This will put it right at it's center point, but then you can offset the player position based on your calculations above. I only did the demo of the Stanley's Parable, but make sure this is what they are doing. They might be doing subtle things that somehow skew the camera view when they make their transitions? Not sure.

@tournamentdan I would think a use case for LOD in OpenGL 4 would be buildings. From a distance I wouldn't think you'd want internals to buildings. That was more of the example I had in mind when I made this.

@gamecreator I believe Josh mentioned in the last beta update that the jitter was fixed. Do you opt into the beta steam version to test that? I haven't tested it yet.

I suppose this is because of the navmesh and AI movement commands. Would be nice to override per controller though so we can do it for the player if we wanted. I know we all wanted the navmesh but I think at some level we expected things to be a little more flexible than they are.

I think maybe some kind of fog could help with this? I know in WoW you can only see so far before the fog kicks in and starts blurring things out. I'm sure there are other tricks one could use.

This used to be a parameter to the character controller back in LE 2.x.

I think you can do this with the skybox can't you? If you have a skybox that has water on the bottom of it that can supplement your actual water plane when viewed from climbing high

I know in .NET you use something like this for the treeview. http://msdn.microsoft.com/en-us/library/system.windows.forms.treeview.getnodeat(v=vs.110).aspx

If you need to do this, create an empty script (I call my dummy.lua) and attach it to that entity. CSG objects will get collapsed and not be seen by themselves unless they have mass or a script attached. ?? What are you trying to do with this? I assume the pressure pad itself is a model/entity? You can attach a script to that model that looks for the player colliding (in Collision() check the entity's name that gets passed in and see if it's player). Then you have the player position from there. Looping like that will always be slower than getting your entities another way. I would avoid looping like that if at all possible, and generally it's very possible to avoid having to do that. If you do have to loop, looping on startup will be better than looping during playing.

Why do you phrase it like that? I thought tesselation was something that automatically happened based on the distance. I wouldn't think we have to do anything in code to say "tesselate" now. This could be a ways off though given his other priorities. Also, an LOD system is still needed for certain models. A house model for example. You'd want far models to not have any interior but the closest to have one (if your game allows you to go into houses). So there is still a need for this.