Rick

128x128 1 meter per tile

There are the 3 models only (minus the character since when I just have the character it runs fine). Nothing out of the ordinary besides the bush having a bone (forgot to take that out), but I rendered without bushes and got the same result so that can't be it. They seem pretty normal to me. These are from Dexsoft. I move the camera to that character models position, then offset it back and up and point at that character. Not sure if that would have anything to do with it. I assume the model viewer would show the hierarchy you are talking about.

Yeah, not sure why 3888 entities are being drawn because there aren't that many on that screenshot so it's probably drawing them all for some reason.

What kind of options do I have with a 128x128 terrain with a bunch of trees, grass, and bushes on it and get reasonable speeds because right now it's pretty slow? I had a program generate the placement for the trees, grass, and bushes and it doesn't seem like it would be to overwhelming population wise. I don't know anything about poly count and what's to high but you can see below the kind of speeds I'm getting.

Is there any way to get ForEachEntityInAABBDo to work with hidden entities because it seems like it's not and I'm trying to use it to find entities around the player that are hidden so I can show them.

To be fair to MrValentine, he never really said that specific comment was rude. We were all assuming that's what he was talking about based on threads. Then based on his later comments we can infer that it was comments in a PM that led to this thread. I guess he'd have to show us those comments so we could judge if it was rude, but I think we all know Josh can be a little rough around the edges sometimes. Clearly he has a right to since it's his engine. Good business or not he can do whatever he wants. Guessing it won't matter in a couple hours as this thread will most likely be gone by then.

From what I can gather it was the things said in a PM which prompted this thread. @MrValentine, ​Josh can be harsh sometimes but this really is a good engine if you know how to program. It's very easy to work with.

You'd have to loop through all the trees and do a distance check. That's to much looping because there really are a ton of trees in the entire scene but because of the top/down view only a handful are visible at any given time. I think the best way to do it is to use ForEachEntityInAABB() and just keep 2 lists and compare each frame and hide the trees not in the current frames list that is in AABB. Way less looping involved that way. That means, however, I'll have to go back to C++ as Lua doesn't seem to implement that function *sigh*. That's what I mean. Think of an RTS view. The majority of the map isn't even visible becaues of the top down angle. I was hoping Leadwerks would just handle this on it's own but it looks like it's not

Any info on this? Is it truly not implemented in Lua?

Thanks Scott. I'll actually give the AABB way a try if Lua has the one function that gives a callback with everything inside the AABB.

What would be the best way to do number 1 without looping through the entire grid? Also how do you put all the models into 1 OC group?

I have a top down view with a lot of trees, bushes, and grass models on a 128x128 terrain. If I just show them all I get like 24 fps. With them all hidden I get like 180 fps. I have also made a logic grid 1x1 and all trees, bushes, and grass models are tied to the center location of each tile in the grid. Because of this I'm able to find a 20x20 grid around the player and show the models in those tiles if there are any. This gives me about 60 fps. The problem with that is as I move it keeps showing more models but not hiding the ones out of camera view so the fps starts dropping. Wondering what kind of options there are for me to keep this area around the player to show these models and hiding all others outside of this range. Any tricks that might make this faster because even the looping over tiles around the player drops fps a decent amount.

Very cool.

You could make a couple different branch models that are very low poly and are smaller segments. Load one instance of each in as your base models. Maybe give them bones at their ends. Store them in a list and when you add a new segment (the vine grows) you place the bone on the new one at the bone of the one in list next to it. Some of the models would have bends in it so the bones give a nice position marker to connect them. I guess instead of a list you could use a tree structure to branch things off. You could also add leave bones also and have a leaf model that you randomly place on each segment. This would give you instancing benefits anyway. So now all you have to do is place a starting place for it to grow and it will. It won't be a smooth growing but it'll grow segment by segment which if there are enough leaves I'm guessing people won't notice all that much as it's more background than anything. It's one of those things you notice once enough have grown but not notice as it's doing it. The next trick would be to get it to hug other objects, like the wall in your picture. Just thinking outloud here to maybe help keep the ideas coming.

When I was doing mine some time ago I would move the camera toward the player by just a little after the pick to avoid clipping into geometry.

Hey, sorry haven't been able to get to this yet. I still plan on it though.

So can I technically do that with all LE entities? Why have :Free() for other entities like meshes then? Sorry I didn't see a Lua forum but other languages have one so thought I'd give it some more info in the generic forum.

Is there a way to free a material in lua? I've tried FreeMaterial(mat) and mat:Free() and both give me an error saying they don't exist.

Instancing is used by default in LE. If you call LoadModel() on the same model 100 times you have 100 instances not 100 unique models. They all share the same material however. You can see this by changing in code the material of one and you'll see them all change. If making basic cubes then make one with CreateCube() and use CopyEntity() on it to make instances. You'll notice your FPS won't drop when doing it that way. However again they share the same material. So assuming you won't want all your instance to look exactly the same you run into the issue of having different materials on your instances. There was a shader around these forums somewhere that allowed you to provide a huge texture file that was broken out into sections. You then use the alpha channel I believe it was, to offset from your giant texture to the specific texture area you want. Yeah it's a pain and in LE3D I think it's being addressed. Instancing can really save your FPS but with the limitation of sharing materials it's kind of limiting currently. I would think a nice middle ground could be instancing of the 3D model but having unique materials if we so wish. Much like position/rotation/scale is unique per instance, not sure why materials can' t be also for instances you so wish.

If you want some basic functionality here is a small script I wrote up. It's very basic. Place the folder in your Leadwerks directory. Reopen the editor. Drag in whatever model you want to rotate. Drag in this script (in the editor it'll be under PI/LE). Press the 0 key to make sure your target index is on 0. Click left mouse button and hold this script object in the scene and drag the mouse to the model you want to rotate and let go of the mouse button. Double click this object to bring up settings and in the bottom group put some values in and click Apply and see it rotate. Very basic but can give you some reusable object to rotate anything you want all the time. More functionality can be added to disable/enable etc. This is just if you want to get what you want done. If you are trying to learn scripting then no worries. I need something like this anyway for a testing situation. http://dl.dropbox.com/u/1293842/Pi-TurnEntity.rar

I believe he's saying make 2 separate model files and code the iteration like was suggested above. He does this with some example models that come with the engine. It's the easiest way IF you know how to program OR you can get someone to do it for you if you don't. At one time I did have rotate thingoid that would simply call TurnEntity() on the first target. So you would have 2 separate models, place the blades where you want, drag in this turn script and target the blades to it. Set some settings of turn direction and axis and it would keep turning once you ran the game or in editor. If you want to give it a try I can find that thingoid.

Will do. Probably get to it tonight or tomorrow. I'll just hardcode it for 4 controllers as I just seem to remember that being a limitation of Windows anyway. I'm going to make it look similar to the other port I did, but I'll have functions to get groups of data since Lua can return more than 1 parameter from functions. Below is the result of polling the joystick. So I'll do something like GetXYZ() which will return the first 3 variables, then GetRXYZ() which will return the others, etc. For the arrays I'll say like GetButton(index) and you can pass in 1-128 for button numbers that you want to check. typedef struct DIJOYSTATE2 { LONG lX; LONG lY; LONG lZ; LONG lRx; LONG lRy; LONG lRz; LONG rglSlider[2]; DWORD rgdwPOV[4]; BYTE rgbButtons[128]; LONG lVX; LONG lVY; LONG lVZ; LONG lVRx; LONG lVRy; LONG lVRz; LONG rglVSlider[2]; LONG lAX; LONG lAY; LONG lAZ; LONG lARx; LONG lARy; LONG lARz; LONG rglASlider[2]; LONG lFX; LONG lFY; LONG lFZ; LONG lFRx; LONG lFRy; LONG lFRz; LONG rglFSlider[2]; } DIJOYSTATE2, *LPDIJOYSTATE2;

You could maybe put a bone where you want the fan to pivot. Do the whole skinning or weighting thing that artists do so the blades are associated with that bone. Then find the bone in code and just TurnEntity on it.

I can give it a try if you like Andy. If it's pretty short it should be fairly easy. So basically after I create the basic open/close/poll I can make methods to get each of the data elements in the structure. Shouldn't be to bad. Also am I right in assuming you can only have 4 controllers? That's what the last library did, and I notice gamecreator's example has an array of Joysticks that is set to 4 also. It'll just be easier if that's a known hardware limitation. I can actually structure this much like diedir's gamepad lib he was using. http://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.reference.dijoystate2(v=vs.85).aspx

The way I started was by looking at how to call DLL's made in C from Lua. Did some google searches on that and it showed me what was required. Then you can carry that over to mostly any library. I only currently know how to do it with C functions and not C++ classes. It gets more confusing when trying to port classes over. I've done a RakNet port (not complete) and this joystick port so far. The basic idea is to write a DLL that exposes the functionality you require. Then Lua can load that DLL and make calls to it.