Question to the Dev team regarding 3D and plugins

I would usually refrain from calling out a particular group, but I don't think this question can really be aimed at anyone else. Unless some of the plugin programming regulars can answer for them.

Is it possible (meaning, I would be doing the work, just need to know if it is feasible), to make a plugin using the SDK that can:

1. Display UV textured polygons (tri, quad) directly instead of via the roundabout Sprite Distortion method?

2. Thus allow for the use of vertex shaders?

3. Access Direct X's inbuilt Rotation Matrix (and other 3D functionality) instead of having to utilize an event based solution?

Thanks.

Construct is not meant to do 3D. If you really want to do 3d why not just use Unity? It is free now you dont have to pay for it at all even if you sell a game with it. What is the point of adding 3d capabilities to an engine that is aimed toward 2d game making?

as for your questions you probably could do something to make it support those things you may have to do some serious workarounds but if you are going to code all that why not just learn how to use Unity?

Moved to Plugins, Behaviors & Effects.

Aeal5566: There is point in 3D features in Construct - take 3D box for example. It's a useful way to add pop-out 3D elements to a 2D level. Obviously Construct isn't going to turn in to a full-blown 3D game creator, but I think these kinds of features are still worth having.

Glamthaus:

1. Yes - the Sprite object actually draws a series of its own textured triangles to achieve mesh distortion in the first place.

2. Your plugin can use vertex shaders if you like, but I don't see much point in a plugin which requires vertex shader hardware support. You may as well do it on the CPU, it's not usually very much processing.

3. Of course, but your own rotations aren't considered by the runtime (eg. determining if the object is onscreen and therefore should be drawn).

Thanks Ashley.

In response to your, well, responses:

1. I see. I had assumed that the sprite distortion must be doing some indirect overhead (well, a lot of indirect overhead). In my testing I could reach about 15,000 1x1 meshes with a 1x1 texture before getting subpar framerates. This is with an 8800 GTX, a decent computer, and a cap that does nothing after generating the meshes.

Apparently Crysis uses 20,000 tris for a single vehicle, with 1024x1024 textures.

I know I cannot do direct comparisons here, but there must be something I can do to increase the framerate. Are you implying that a 1x1 sprite mesh is more than 2 tris or a single quad (would explain a lot)?

Just to clarify, the method I'm using currently is creating 1x1 meshes as faux polygons (tri or quad). You would know better than I what kind of overhead that might create.

2. True. Thanks for your honest answer.

3. So essentially I should only really be getting bottle necked by what I display at runtime (barring exceptionally sloppy programming on my part, of course)?

Thanks again.

Edit: Extra clarification in 1.

Well, if you want hardcore Crysis-level performance, you're going to get in to the more complicated aspects of 3D programming. Games like Crysis use special features to optimise performance. For example, the 3D world geometry itself is in a special kind of vertex memory, called a static buffer, which is kept in GPU memory for maximum performance. Construct does not (at the moment) use static vertex buffers because they're not usually needed for 2D games - basically all geometry is generated on the CPU and sent to the GPU every tick. This is actually most optimal for most Construct games, because nearly everything changes every tick, so it's not worth keeping vertices on the GPU.

So yeah, if you're going to do performance tests involving thousands of vertices, you'll probably never get the same results as a professional 3D engine like Crysis. You might simply be using the wrong tool for the job.

Oh ok. Well that is good to know.

It isn't really that it is the wrong tool for the job. I'm not expecting Crysis type performance, I was just using that for hyperbolic contrast . I'm mainly trying to establish what our limit is for a 3D engine in Construct.

As it stands, based on my testing so far, you can definitely pull off ps1 or n64 graphics with decent frame rates, which is cool.

I'll keep looking into it, anyway. Thank you for your responses, made me more at ease knowing that it is more the nature of Construct and less the ineptitude in my programming that keeping the frame rates at what they are.

Thanks again.

EDIT:

Aeal

I'm doing this because I enjoy the learning experience. Reading about and then coming to understand in depth the different concepts involved in 3D programming has been well worth the effort.

its not really useless aeal. having subtle 3d can add a lot. were not trying to make a game in 3d space here. just having 3d assets for things like backgrounds or 3d graphics on a 2d game plane ( like a spaceship thats 3d in a side scrolling shooter). having the ability to do this easily would be very nice. my at school demo wouldve looked alot more boring if the pencil were just a sprite. but having a simple 3d asset made it really cool looking. if adding a 3d asset was simpler than inventing your own rotation algorithm, and building an object out of willynilly points with special events just to handle sticking polygons to those points wouldn't you think that would be kinda nice? its not required, but its things like this that make construct set the bar, and the reason we all fell in love with it in the first place, don't ruin that like so many before it have because they lost sight of their original goal.

Yeah, it'd be nice to import objs and textures, but Construct isn't even 1.0 yet. No commercial game using Construct has even been successfully released yet. I'd rather see the developers focusing on making this the best 2d engine available instead of putting too much time into adding 3d features.

3d is complex, 3d is always adding a huge overhead in terms of complexity - Not sure it'd be smart to get into all that just yet. And as Aeal pointed out, there are a handful of very capable engines now that completely focus on 3d (Unity) and some even have event based systems (UE: Kismet, CryEngine: Flowgraph), so if you wanna go 3d, those are probably your best bet.

Yeah, it'd be nice to import objs and textures

Just wanted to say, I'm already doing this within the cap I've been working on.

If I get time I might be able to strip out the transformation side of the code and turn it into a plugin that will allow everyone to use low-poly objects if they so desire.

Thanks for giving me the idea .

It would be great to have simple low poly objects like lets say max 1000 polygons and I'm pretty good in makin uber low poly models so it would be great for me and you could make it small so it doesn't really matter if 100 polygons or 10 000....

*dreams on*

I would pay for an plugin like that

I don't recall saying this would be useless I think I said its more trouble than its worth. If you want to do FULL 3D with animated meshes and other things like that it would not be worth trying to bend the codebase to do what you want it to do, it would be better to go use an engine meant to do 3D if you want 3D not bend a 2D engine into making a 3D game.

Making a plugin that could import simple static meshes has its value but you also have to think about how big are these meshes going to get before we start to see slow down. the 3d box now is 12 tris and Im not sure how many you can have on screen before you see slow down but even things like barrels and crates take up any where from 100-300 quads which means 200 - 600 tris the equivalent of having 50 3d boxes on screen in one object. making a Higher poly model 1000-2000 quads(2000-4000 tris) is equivalent to 166- 333 3d boxes on screen. In one object. That is a lot of polys to deal with