That’s called “broad phase” collision detection. Basically doing approximate collision detections by using a distance check or something. Other ways are using bounding boxes, bsp, quad tree, collision cells, etc. construct already does it somewhat with the overlapping condition.

Anyways you can do that with events but you’d have to actually do it and test if it improves performance. The overhead of implementing those things with events can often result in things being slower oddly enough.

Anyways the logic of the distance check you describe could be:

For each sprite

For each terrain

Compare distance between sprite and terrain <100

Sprite overlaps terrain.

But with events you already reduce the terrain loop by doing this instead:

For each sprite

Sprite overlaps terrain

For each terrain.

But that’s mainly because internally construct can filter the objects faster than you can do manually with events which are slower.

You other idea of adding and removing objects as needed is another idea. But you’ll have to test it. This plugin was made so you only have to make events to update objects you want to move. All the static objects will just redraw fairly efficiently. Adding/loading on the fly would be slower but it may end up being faster in the long run. But you’d have to actually test it out.

All right, thanks, I'll be testing. I want to streamline the code. My current performance is smooth solid, but it hits 95% to 98% on i78750h with 1050ti and 32gb of hyperx ram. 70% of it are draw calls. Each terrain sprite has 4 meshes attached to it and there are 4 rojo3d plugins on different layers. SO my hope is that I can lower the cpu usage, and with array technique i can lower the number of 3d objects. Will test :)

I aim for simple and easy to read with my events if I can. Using arrays to store object info instead of sprites may or may not be better, it just depends on how you want to implement it.

You can sort arrays, but you can also sort sprites with “for each ordered”, just use the stop loop action when loopindex=0 if you just want the closest. Or use a higher number to do stuff with more.

The only time I use an array for terrain is if it’s in a grid formation, in which case a tilemap can work too for 2d. If the terrain is different sizes and whatnot I’d just use sprites.

Not sure I grasp your distance calculation. Would a 3D distance calc work better?

Sqrt((x1-x2)^2+(y1-y2)^2+(z1-z2)^2)

I have no technical expertise with the fov behaviour. I find behaviours seldom do what I want so I’m more inclined to do stuff from scratch than do things to bend behaviours to my will.

For your last question I think there’s a misunderstanding.

You get the position of objects with the x,y and z expressions as I recall.

The orientXX/Xy...Zz expressions is the orientation matrix of the 3D object. Aka. How it’s rotated.

You can think of those as three vectors.

OrientXX/Y/Z is the left vector of an object

OrientYX/y/z is the up vector of an object

OrientZx/y/z is the forward vector of an object.

Ok, cool. Thanks for the answers and 3d distance calculations. I will think of its use for sure.

But let me elaborate. The distance would be there to first check for objects within radius form the actor, and after that those objects that are near the actor are checked for collisions with it. Atm I'm doing isOverlapping,for each overlapping to test collision with grounds and walls for all actors. But since this is the only top condition to pick and check collisions, my idea is to get rid of those sprites and just test for nearby 3d objects with data inside array and then do radius check if actor is colliding.

Also the level loading is dynamic, or rather positioning of the objects is based on what is in the level array. If player has LOS to position, I pick idling terrain sprite, then set all of its values from data stored in array, then pick mesh and set it's parameters with values taken from the sprite. I've created level exporter you see. It exports everything in to array. Then I'm applying that data live based on objects XY in the array using LOS. This way I can have big levels with number of sprites under 200. But for each sprite I do need to update 3d mesh, static once, but others like those for actors or liquid and billboards all the time. In this case it feels like sprites are only a middle-man, and could be completely omitted. I already got rid of sprites for billboards like trees etc. But my worry is that 2k objects in array that needs to test against number of actors so that i can select which ones will be testing collisions against might impact performance more then if i have 111 terrain sprites at all times.

Idea is to narrow it down by first testing which level objects are visible to the player and then put them all in to it's own array and do sorting based on distance and only check collisions for those objects that have distance lower then some value, and stop the loop. And then do the same for other actors in the scene. I imagine this is how its done when picking overlapping objects, with the difference that if the sprite object has collision poly with more points then 4, like in my case my ellipses have 12, that collision check might have same or bigger impact on performance then simple distance check for nearby objects and then testing each for collision with radius from the center of each object.

Ik this is a lot in realm of theory. I guess I have to try it and if it won't perform well, I will get back to using sprites.

The plugin is at the point where some design choices early on make it hard to change things without breaking stuff. Plus the event system's speed and limits make it hard to allow the amount of flexibility I'd like without being overly verbose and complex. Anyways, that's partially personal opinion. Construct makes some complex stuff simple and some simple things overly complex.

As for your wishlist:

*The view distance is just an artifact of how the fog is implemented. There are pros and cons of either. Rewriting the plugin to have alternative options for everything would be an option i suppose.

*As I recall I try to fit the shadow frustum to just fit around the view frustum for maximum shadow detail. It's not perfect because some things off camera aren't being included due to some approximations on my part. There are alternate ways to do it, such as fitting the shadow frustum over the whole scene, but the tradeoff is giant scenes would have low res shadows. But I agree more work would need to be needed with shadows but it turned into just fiddling with settings to see what works well which was too time consuming.

*blend modes would be nice.

*opacity is already doable. You just have to turn on "transparent yes" in the object settings. The caveat is it's done per object. So it just draws objects back to front. Per polygon would be better, but more complex to do with how the renderer is implemented, also it still would have cases where the sorting would be off. Best would be an algo called "depth peeling" but it's slower.

*normals are already in the plugin. As long as an obj file has normals in it you'll have normals, which is used for smooth shading. If you mean normal textures, then no, only one diffuse texture is used.

*Collisions and raycasts are highly requested things. I have a good idea how to do them but I don't find I enjoy finding a way to make it usable in the limits of construct's event system.

Overall, I may work on this more, but I'm more inclined to work on other things first if I find the time and motivation to code.

-cheers

Thanks for the answer. I meant normal maps. Shadows are not usable in first person view unfortunately, because they shrink the moment the object casting the shadow is at angle and behind the camera. Transparency is also not very usable in many cases because it does glitch often and also if I recollect correctly mesh with transparent texture will show back faces and also becomes more white, and I didn't find an option to set object's opacity other than either trough transparent texture or transparent layer ( maybe I've missed it? ). But that's ok, for now, I work within limitations. Since I'll be doing proper mesh for each sprite type, then for shadows I might end up just doing the old school circular gradient or something. But I hope something will inspire you soon to work on it. Cheers M

R0J0hound

Brilliant. As you wrote this is probably only for squarish type shapes. Still it will be useful to have. I'll be implementing it.

On the further note, IK you won't probably do anything more with the plugin, but there are aspects that if improved would make it a perfect 3d plugin (for me, in order of importance):

- Camera view in the distance should be a flat plane and not sphere, so that all objects in the viewport appear and vanish together.

- Shadow matrix should be independent of camera view or layout angle. Camera view is changing the layout angle making shadows shrink and expand.

- blend modes for meshes

- Opacity for meshes

- Normals

- per poly collisions

I did look in to the plugins code, but I'm too weak at coding for it.

Still, I am very thankful for this plugin. It finally allowed me to realise potential of c2 and my ideas ( never was happy that c2 is only 2d, and made several dozens of prototypes, some with your help, but never fully engaged with it to work on a complete game )

Best

M

R0J0hound

Hi, I'm having a problem with creating a mesh and I wander if you could help me.

Since transparency is causing a lot of glitches depending on the angle of the camera, so I figured I need to create a mesh that is in a shape of the sprite I want to display as billboard. But I can't figure out how to get my code to work. I have imagepoints corresponding to verts I want to create, but after looping trough them I'm getting a broken mesh. If you could help out that would be great.