irina

Yea I've seen it, it's basically just three.js+some libraries that you have to pay for though so i wouldn't really call it great. All the coding is done in javascript and three.js already has an editor that can do what it can for the most part. the advantage of Q3D over these systems (playcanvas/blend for web) is that you can do all the coding super easily with the super classes / picking and event sheet editor Q3D makes available. It'll take you 5 minutes to make pong in Q3D+C2 vs. 30 in playcanvas etc. and the construct 2 engine is a lot better in terms of handling input/sound etc. than any of those other engines. This is the main reason i started this project even with those other ones available, the work flow makes things really fast once you're familiar.

kmsravindra

All i can think of is that there was a change with Q3D sprite (due to a bugfix in three.js) which now makes "sprites" in three.js scale with their "control box" (this previously didn't happen). So check if you have any Q3D sprites with XYZ size greater than 1,1,1, by default they in 2.3 used to have something like 100,100,100, but now in 2.4 i changed it to 1,1,1 because this problem was occurring. The migration would have messed this up and i forgot. set the value to 1,1,1 if you want their size to be the same as the one shown in the layout. they might be growing very large and covering the screen in the background or something.

andreyin

There are various examples for different things and im working on more, aswell as a manual with tutorials

now. I could make an example of that very easily/quickly, and i believe some of the existing examples have a similar camera control implemented already.

GameThirsty

Yes, frustum culling is automatically enabled, and improves the performance significantly.

I've started writing some documentation today.

I've begun writing 33 pages (with pictures and descriptions) on "getting started" with the various core features of Q3D. I'm going to try to add a little every day so i'll hopefully have some useful documentation in not too long (perhaps a few weeks).

—

Yea I had to design around minify because Q3D requires plugins to communicate in a way construct doesn't readily support with some of its features (notably it's minifier) this has been an issue a lot of people run into.

—

Strange, it's fixed for me. How can i reproduce it?

Make sure you're not minifying the project. Because of the way the minifier works (advanced optimizations) it wouldn't be easily possible to support it with Q3D in C2. If you want to minimize file size you should run C2runtime.js and any large js files from the export through a less harsh minifier like : http://jscompress.com/. This will retain all functionality but shrink the file size by around 50%.

nemo

The issue is that your models have skeletal animations that arent used then. You exported them with the data without realizing and now that q3d supports them its wondering why that data is there.

version 2.4 is out, with changelog on the main page. Download from the same page as before.

I'll be focusing more on documentation/examples now, only editing the main code base if bugs need to be fixed.

Ubivis

your issue is that you are using "local space position"

local space position moves the object relative to its own coordinate system, which is moving. It seems you want the object to move towards "destX/Y/Z", so what you should do is "point" the bullet at that location using "look at (parent/world)" and move by local space vector (0,0,speed) per tick

Another option if you don't wish to affect the rotation is to set the objects position per tick in a "parent/world" type set position action. You'll have to subtract the current bullet location in xyz from the current destination in xyz, then normalize those values by distance (divide them by the 3D distance) then multiply them by speed.

basically:

// get the difference vector

delX = bullet.destX-bullet.initialX

delY = bullet.destY-bullet.initialY

delZ = bullet.destZ-bullet.initialZ

// get the distance and normalization factor

dist = sqrt(delX^2+delY^2+delZ^2)

// normalization factor is multiplied by the speed,

// so basically the del vector becomes a (unit vector)*(speed) when multiplied by normalization

normalize = speed/dist

// move the object

set parent/world space position:

X: bullet.x+delX*normalize

Y: bullet.y+delY*normalize

Z: bullet.z+delZ*normalize

Ralph

you can export animations with the blender exporter:

https://github.com/mrdoob/three.js/tree ... rs/blender

for now only morph animations are supported but as i've stated skeletal is very close.

—

I'm serious

I have a little break between exams and I decided I'd try and finish up what I had since I was so close to release already. I'm sorry for making everyone wait so long but things take a lot of time .

After this release I'm going to make a lot of examples and some documentation for users. The plugin architecture is largely static now and I don't see myself making any new huge changes that could make any future documentation super outdated. Future updates (likely 2.5-2.6) might include particle effects and custom shaders, as well as eventually proper support of saving and the debugger, and after that this plugin is going to pretty much be feature complete. I could go on forever updating however Q3D is (and almost always has been) largely at a point already where it's pushing the limits of what can be done with Construct 2. As I go along there also always additional optimizations I make to try and improve performance and usability, and as always feature/example requests are welcome.

What I ask of you all now are for the most wanted Q3D tutorials and examples. These will guide me in the process of making useful documentation.

Im in the end stages of the finishing the HUGE 2.4 patch which adds support for 3D physics and skeletal animation. I'll have to warn people that this version is substantial and I've forgotten most of the changes i made (there were plenty) while also updating to the latest three.js version. Because of the large degree of changes this MAY break some projects, however all of the changes were quite necessary in order to keep things up to date so i apologize if this is the case and of course will offer advice as always to anyone who needs it. I didn't keep a detailed changelog because work spanned over a long period and i'd simply forgotten, so i apologize for that aswell. In any case the update should be out very soon (and i mean it this time, perhaps in the next 2 days)

DatapawWolf

Because of the way modern engines work, the difference between small sprites and big sprites in rendering time is usually pretty small, the main issue is with screen resolution and pixel shaders. If a pixel shader is covering more pixels thats what's going to slow things down, much more than just having a large texture. This means if a low res sprite is stretched it's still going to have almost the same GPU cost as a un-stretched high res sprite with a pixel shader, if that shader incorporates any kind of blending (and i'm pretty sure even if it doesn't blend). Modern engine architecture generally means tiles are more expensive than large quads, so it's not really a fair comparison to say just because your game looks lo-fi and has tiles like 16-bit era games it should run better. Tiled images are actually a lot more expensive in most cases than a chunked "Braid style" map, if you're not counting the memory savings.

Really the issue is that mobile CPUs are slow and a physics engine running through JS isn't going to be able to squeeze a ton of performance out of a mobile phone, especially running on-top of the expensive event/picking execution system. There's a performance tradeoff you get just by using construct, even if you barely have anything in your project.