thanks for the examples, the first one did it.

Seems I wasn't getting any results because the erase object needs to be on top of the other objects (duh!) and works within a single layer.

this will be useful, I'm sure... I plan to use it to mask shadows out of an occluded object!

Yeah it can certainly do that, I was considering it in the other thread, but the way things are heading for me, i don't think I'll have the resources for even more objects lol.

mmf2 has this in an extension I think, parallaxer object I think.

How well does it work in that? Hmm just checked it out on youtube, works fast, and shows it can be done, well something similar to meshes anyways.

The shader request just distorts the image depending on brightness (height map) and distance from a point.

Also, a shader makes it VERY slow.

Really. It's slow, even in modern hardware. For that performance, I'd rather go full 3D.

I think that's just the case for the parallax occlusion shaders. This one would basically do what the distort shader does, only differently. Meshes would work great if the tools were there, but currently for what I need, they're not practical (they'd work fine in a shoot-em-up or top down game tho). I can't create something that converts height maps to .mesh files. I wouldn't even know where to begin. Each one would be different shapes.

Though saying that, even meshes would have issues, as it would be effectively making displacement mapping for everything, and anyone in 3D could tell you that's a killer for real time, hence the creation of shaders to approximate the effect of there being more polygons than there is. A mesh wouldn't have the polygon resolution to capture the difference in height between stones in a wall or the knarly shapes found in the bark of a tree like the shader could. Even though using meshes would allow for better looking depth, and even interesting effects such as overhanging objects, arches and so on (from the side) that change position convincingly.

Bleah, it's not fair, lol!

Doing them by hand would be out of the question for a few reasons

1 ) too many of them (talking well over a thousand or more - no not on screen all at once, hehe)

2 ) matching the edges of each sprite up using the mesh tool, can't be done by hand, would result in lots of gaps and constant refining to the point it would never be done. While #1 isn't too bad, #2 would ruin all the hard work and effort.

I do agree that meshes WOULD work better, and ultimately look better. But unless someone can come up with a way to convert height maps to mesh files (which would IMO be the best method of "modeling" mesh files in construct), then for what I need, a shader like requested is still probably the only way to go.

There is one other option, that would be to create each level of object movement as a separate layer, but yeah, ouch ouch ouch, lol! There's going to be enough real parallax layers going on without adding 20+ per sprite, so that's like a worst case scenario hehe.

It should be layer based unless you enable Z layering in layer properties, I think.

Woohoo! Excellent, thank you!

Quick question really. Is the depth used by meshes universal, or layer based?

For example, two objects at a depth of 10, one object is on a layer behind the other object also in its own layer. Are those objects sharing the same space as each other, or is the object on the layer above seen as higher up and therefore not clipping the object in the layer below, regardless of the depth of that one.

Please say layer based, please say layer based.

So many old games could have been soooo much more fun with something like this (no having to stand around waiting for your mate to get back from the bathroom and his motionless character holding you back), or those old sports games, or football games. I'm trying to find an excuse to use this in mine now, grr, lol.

Awesome, very very cool. Now do it with four players!

Meshes can be kinda hard to grasp for people new to making games or unfamiliar with 3D... and the ways of rotation you can do with them is kinda limited by default means. They're most easy to use with topdown 3D stuff (or completely sidescrolling stuff) - anything beyond that requires a lot more thought and math to pull off. I was thinking about using meshes for my danmaku thing but ditched the idea for now since I couldn't be arsed to think about the math involved with moving stuff through the screen properly.

EDIT: The mesh editor itself is simple to use and easy to grasp, and so is loading meshes at runtime. Doing UV distortion stuff via the events is where things get a bit more complex, and that's what is required to pull off basically all the 3D stuff people have been asking about.

Yeah, that's true, I wouldn't want to try model anything too complicated with them either (would be like modeling in Sculpt3D all them years ago *shudders uncontrollably*), but various shaped surfaces and using the normal map shaders for the smaller details, they look to be quite capable.

They look to be perfect for the shoot-em-up environments though. I was looking at R-Type Dimensions earlier for the XBox, and the sideways scrolling view of it's 3D mode could easily be duplicated with them, including a small number of actual enemies, while the rest could be pre-rendered to appear three dimensional. Though don't know how one would go about getting the realtime lighting effect.

BTW turns out the mesh was loading correctly, just the amount of displacement wasn't matching once inside construct and became unnoticeable (but I'm not giving up yet! lol).

I think most people who are using 3D in Construct are using some combination of 3D boxes and 3D mesh distortion. There are a few open bugs on the tracker about both though, which might be preventing more people using them. Daiz raised a good point that generally 3D stuff is harder, more mathematical, and more difficult to reason with in your head, which is why 2D is quicker and easier to use.

Yeah, the more advanced 3D stuff is going a bit overboard for a 2D app IMO. Though I love seeing what people manage to create with them. I could certainly see them being of great use in top down games like Diaz mentioned just then too. I suppose it's possible to layer them (since they are still 2D sprites), so suddenly "flat" tree canopies would have all kinds of depth to them, banks of rivers would appear to dip into the water, even some kind of isometric feel to larger buildings. Hell I didn't think of that earlier, wow, awesome! lol.

Seems like they're useful and capable of quite a lot of subtle little tricks and effects before even having to worry about how to rotate them in 3D space (which even having worked in 3D most of my adult life, I wouldn't be able to do via mathematics lol) or other advanced effects. Course I'm still thinking of more basic usage for them, more along the lines of enhancing 2D a little, rather than replacing it like I understand many are hoping for. Since I'm still in the "construct should remain a 2D app" camp and it's unlikely I'll change my mind on that.

In my request thread for a specific shader (if you can write .fx shaders please take a look, lol ). Another user suggested meshes, I'd heard about them but hadn't actually used them or seen any documentation on them. Even found a tool hidden away that lets you edit them, which I didn't know existed.

Now while there's no way to create them automatically that's within my knowledge, thus rendering them impractical for my needs *cries*. I did realize something...

..It seems the majority of people wanting 3D in construct are ones wanting those 3D looking backgrounds for the bullet hell shoot-em-ups. Well how come your not using these meshes? They would work perfectly for those kinds of backgrounds required in those kinds of games. And by creating the artwork to be used on them in a pre-stretched way, you'd easily avoid distorted textures. The vertexes move X and Y and there's an impression of moving in the Z axis, so there would be nothing stopping you from making damn near anything in "3D" with them, and having your backgrounds look as 3D as you want them.

So yeah, I just wondered what I'm missing, cause they do seem perfect for that particular task, and anything more complex than those, could be pre-rendered and nobody is going to tell the difference really.

So yeah, made this thread cause maybe with getting a discussion going about it, we can learn more about them, they look very useful and I'm certainly curious why they've not been embraced by those wanting 3D added to construct.

Oh yeah and anyone who can write shaders, request thread n all that *smiles sweetly*

You have to create the heightmap via some means anyway, so you could just write a simple construct app for yourself that makes meshes based on heightmaps and then saves them so that they can be loaded at runtime.

Ok scratch everything I had just written in this reply and had to delete after finding a mesh editor in the tools directory. Ok so meshes basically do (I think) what I'm looking for. Only loading a mesh in makes no difference to the sprite, so any changes made in the mesh editor are ignored. Unless you have to then edit each and every column and row in a sprite by hand.. ouch, considering the number of colums and rows that would be required per sprite.

Yeah, a shader will just be so much easier and more logical, even if the final effect wont be as pronounced as it would by using meshes, I'm afraid they're not an option until there's some documentation about them and a way to do hundreds of sprites automatically using height maps.

Thanks though, I'm sure I'll find a use for meshes with something else, they do look useful, just impractical by the looks of it for this kind of thing.

You know that my usage of bullet behavior is for the grapple thingy shooting from my character, right? ^^ The grapple actions will be done seperately, done mostly from a personal .cap someone posted a year ago. I'll just be copying that. Think Samus's Grapple Beam from Super Metroid.

Yep I knew that. I've never played Metroid Prime before (was a computer dude not a console dude), so went to have a look on youtube, saw a few examples of that particular grapple.

I'd totally make it physics now, lol. Could do something like switch all the movement controls off once the grapple has caught something and just use physics and various forces to control swinging about and so on. The beam could I would think be easily made to hinge together too. Or heck, I wonder if bones work with physics, Ashley did mention the possibility of ragdolls eventually, and it's the same principal.

Yep, physics for the grapple would be awesome!

For the actual firing "mechanism" you could do a search around the forum for a recent thread (from within the last three weeks I think), where someone posted an example of finding the closest solid object from a particular direction, which I would think could be used for the point of attaching your grapple (if within a certain distance) then you just follow that up with the actual animation of the grapple being fired and moving toward the target, attach the physics 'beam' and all that jazz, that would be what the player see's and bobs your grapple wielding uncle.

Wait a minute.. was that you who posted that example I'm talking about? Cause it looks like something very useful for what you're doing.

AFAIK the right is 0 degrees, and the angle everything faces by default.

Look at a sprite and you should see a small arm coming off the center of it, moving that will change the angle within the layout and should change the default angle for that particular sprite then.

The bullet behavior I think is made to go in the direction the spawning object is facing. But I doubt it would be that difficult to make it choose a random direction either.

Since this is the grapple, right? Are you sure using the bullet behavior is a good choice? While more in depth, you might find you get more control by setting up it's behavior through events alone, and just use the bullet behavior for bullet like objects. (I know, I know, depending on deployment, a grapple could be considered a projectile). But for your purposes maybe something else would work better.

Personally I'm tempted to suggest using physics for it.

Couldn't you just create a mesh out of the heightmap and be done with it?

Don't know how, and how complex would that be to do with a large number of very different looking images? Some could be walls, some bark on tree's, some rocks in the ground, some window frames, some weird looking plants. I couldn't find much info on mesh/distort but by the looks of it you have to plot out the intersecting points of a grid across an image, that would be nigh on impossible for something like this

Well if you use the dummy sprite, you could have it appear as something, maybe a puff of smoke or crackle of electricity etc. at the end where the grapple pops out. That way the sprite has more than one use to it.

For cleanliness sake though, I'd probably go with the variable suggestion of Mipey's, unless using the sprite method offers something extra for what you have in mind.