R0J0hound's Recent Forum Activity

  • Hi,

    There is no anti-aliasing done.

    To use a texture on a model there are two steps

    1. Load the texture from a file or sprite to a tag. The tag is to refer to it later.

    2. Tell an object to use a particular loaded texture. Should be an action under 3D appearance or something.

  • You probably could get better performance by reducing the number of instances of the plugin. But I guess it depends on what you’re doing.

    With the tags it’s just one per mesh. I was considering adding a group feature but I don’t have enough to time to implement it and test it without breaking things.

    When creating 3D objects you can copy another object so you don’t have to set up each attribute. But other than that there’s no way to change a bunch of objects at once without a loop.

  • 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.

  • 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 behavior. I find behaviors seldom do what I want so I’m more inclined to do stuff from scratch than do things to bend behaviors 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.

  • 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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • So, creating the mesh is something you’d probably do just once. Like:

    Start of layout

    — vertex (100,0,0)

    — vertex (100,100,0)

    — vertex (0,0,0)

    — save as mesh “triangle”

    Now it looks like you have a bunch of imagepoints that make up the polygon border of the image. You need to convert that to triangles. One simple way to do that is to do a triangle fan.

    Something like this. P is the imagepoint you want to start the fan from, best if you use a concave point. Ipx and ipy is sprite.imagepointX/y, and count is sprite.imagepointCount. I just didn’t want to type that all out. 

    Var p=1
Var i=0
Start of layout
— repeat count-2 times
— — set i to p
— — vertex(ipx(i), ipy(i), 0)
— — set i to (loopindex+p)%count+1
— — vertex(ipx(i), ipy(i), 0)
— — set i to (loopindex+p+1)%count+1
— — vertex(ipx(i), ipy(i), 0)
— save as mesh “triFan”

    Notice it matters what imagepoint you start with. See below. Also this won’t work for all shapes, but hopefully will. For any shape that doesn’t work with a triangle fan, you’d need full blown triangulation of polygons.

    Also I guess I didn’t specify uvs. For any imagepoint you can convert it to uvs with

    U=(Sprite.imagepointX(i)-sprite.bboxLeft)/sprite.width.

    V will be similar but with y, top and height.

  • There isn’t a distance limit so you just have to play with the numbers.

    Basically it’s a mix between the acceleration and spring stiffness. When the spring is stretched far enough it will counteract the acceleration.

    The damping makes it less springy. Set it to 0 to see it bounce all over. The damping slows it down.

    320 and 240 were just half the 640,480 window.

    I used the layout size to limit the position we use to the scroll area. It’s not needed if you had unbounded scrolling.

    The a and d variable are just the angle and distance from the camera to the mouse.

    There’s always some feature I forget about with my examples. You may still be about to use screen shake after you set the mouse position. Or we could do our own with some random values added to the scroll position.

  • CustomMovement is unwieldy, I never use it.

    Here's what I came up with:

    dropbox.com/s/jb23i3gx19ccktl/spring_camera.capx

    or radial instead

    dropbox.com/s/tt5p35r8r640mna/spring_camera_circle.capx

    Basically the camera is controlled by a damped spring which gives nice easing in and out. There are three variables you can tune:

    acceleration controls how fast it moves.

    stiffness controls how far you can look and how fast it returns to the center.

    damping gets rid of bouncing. higher values also make everything more sluggish. too low and there will be overshoot.

    Edit:

    Here the spring is applied to the whole camera instead of just the look around:

    dropbox.com/s/1lfz90zxj92bd9i/spring_camera_whole_camera.capx

    Kind of gives the impression of a real camera operator.

    Edit2:

    dropbox.com/s/42gs4g1tljsp35n/spring_camera_whole_camera2.capx

    Fix to ease down when scrolling to the edge of the layout.

  • Probably the solution is to not use lerp. Instead move the scroll around by applying an acceleration which would eliminate the jarring. The idea is you’d want an ease in and out instead of the jarring ease out that typical uses of lerp provides.

    I don’t have the time today to make a complete example but the basic logic would be:

    Mouse is in edge region? Accelerate camera to a max distance

    Else decelerate back to 0.

    Anyways there’s more to it than that. The acceleration provides the smooth motion and you can utilize a formula so you can gradually stop at a specific location.

  • That’s the only fancy thing you can do with expressions.

    From most complex

    TypeName(index).behavior.method(param1,param2)

    To most simple:

    TypeName.property

  • One way that’s pretty simple is to give your sprite an instance variable “target” and place the waypoints on the layout in the order you want to follow. You could alternately place the waypoints in any order and use an instance variable to set the order.

    Anyways the events would look like this: 

    Every tick
— sprite: move forward 100*dt pixels

Sprite: on collision with waypoint
— sprite: set target to waypoint.iid+1

Pick waypoint instance sprite.target
— sprite rotate 60*dt degrees toward (waypoint.x, waypoint.y)

    The 100 is the speed, and 60 is how fast it turns.

  • Is the gltf file you’re using one of the ones included in examples for this plugin?

    I helped with the initial gltf loader part of the plugin. The plugin should be able to load any gltf file saved as embedded from blender, or any other program.

    With the gltf format it has three different variations:

    Gltf + bin

    Gltf embedded

    Glb (binary)

    The loader in this plugin only handles the embedded variation. Which seems like the format you’re using since it works with the Babylon test bed.

    Anyways if you’re able to share the gltf file or a c3p project with the file it may help to find the issue.

    From the error it looks like something isn’t loading correctly.

    Mikal

    It may be something as simple as the the exporter that made the gltf file not adding all the properties that the plugins loader expects. I thought it follows the spec but this may be a case where if that part isn’t there you’d just add it from the other info in the file.