Q3D V-2.4 [3D Physics + Skeletal Animation UPDATE]

Post your completed addons to share with the community

Post » Wed May 31, 2017 5:16 pm

fuego96 wrote:Hi, it's been a while. To anyone who knows the answer to this question (I've searched). But to setup the context, lets say we have an .obj with three cubes.

I see the "SYSTEM --> For Each child" and upon iteration, the .idPicked property shows unique numbers. Great.
But applying something like "Q3DMaster --> Set object visible" to false doesn't seem to have any effect.

QUESTION:
Does the "System --> For Each child" work for loaded .obj that has children (the three cubes in this case) at all?
Or is it only useable for Q3DModels instantiated/created in C2?

WHY:
ThreeJS's Object3D.traverse(callback) seems to fit the bill for this type of useage. Just asking :-)
https://threejs.org/docs/#api/core/Object3D


Super interesting question! One of the limitations I have been living with is a low object count. If I try to do lots of objects, I quickly overload the CPU. Being able to do instances of objects like you can in Babylon3d would be great. @quaziGNRLnose, is this possible with Q3D?
www.simbucket.com - HTML5 Science Simulations / https://www.airconsole.com/#!play=com.n ... obotrumble - Robot Rumble on AirConsole
B
46
S
11
G
20
Posts: 363
Reputation: 14,199

Post » Wed May 31, 2017 7:10 pm

cjbruce wrote:Being able to do instances of objects...


I've just tested with ThreeJS/JavaScript and it is possible to do so -- absolutely.
In fact, the name of the mesh (obj's 'o' key) is retained, where, you can access it by the child's .name property. From there you can then translate, rotate, scale etc...

The caveat in going that route is, of course, the missing "IDE" but other than that, the plumbing work in ThreeJS is already there.

EDIT:
Just noticed that .PickChildren is also available for Q3DModel plugin (that loaded .obj files) but doesn't expose the .name property. Why?!

EDIT 2:
I see why. The OBJLoader.js included in Q3D is actually a different implementation than Three.js and only accounts for vertices, normals, uvs and disregards the rest [strike](including object names).[/strike] Perhaps this was done to allow certain use cases in the C2 editor that, over time, was never meant to be.

EDIT 3:
Oops. Not true, the object name supposedly looks like it is saved... Now curious as to why it isn't available.

EDIT 4:
Aha... it's because it was a design decision. Okay, question answered.

@cjbruce
I don't think we'll ever get that feature in the current Q3D -- despite it being perfectly doable in actual ThreeJS + JavaScript. That is, unless some major work is done to the OBJLoader (and some other implementation files).

*sigh* what a downer. :(
Last edited by fuego96 on Fri Jun 02, 2017 10:49 am, edited 4 times in total.
I don't need a better iPhone, I need to be better.
B
23
S
9
G
20
Posts: 67
Reputation: 11,736

Post » Thu Jun 01, 2017 2:05 pm

fuego96 wrote:
cjbruce wrote:Being able to do instances of objects...


I've just tested with ThreeJS/JavaScript and it is possible to do so -- absolutely.
In fact, the name of the mesh (obj's 'o' key) is retained, where, you can access it by the child's .name property. From there you can then translate, rotate, scale etc...

The caveat in going that route is, of course, the missing "IDE" but other than that, the plumbing work in ThreeJS is already there.

EDIT:
Just noticed that .PickChildren is also available for Q3DModel plugin (that loaded .obj files) but doesn't expose the .name property. Why?!

EDIT 2:
I see why. The OBJLoader.js included in Q3D is actually a different implementation than Three.js and only accounts for vertices, normals, uvs and disregards the rest (including grouping names). Perhaps this was done to allow certain use cases in the C2 editor that, over time, was never meant to be.

@cjbruce
I don't think we'll ever get that feature in the current Q3D -- despite it being perfectly doable in actual ThreeJS + JavaScript. That is, unless some major work is done to the OBJLoader (and some other implementation files).

*sigh* what a downer. :(


Thank you for looking into this! I agree with the design decision. Given the choice between using C2 style picking that just works in Q3D, and the confusion that arises with "meshArray" in B3D, I would go with the simpler-to-understand Q3D approach as well.
www.simbucket.com - HTML5 Science Simulations / https://www.airconsole.com/#!play=com.n ... obotrumble - Robot Rumble on AirConsole
B
46
S
11
G
20
Posts: 363
Reputation: 14,199

Post » Fri Jun 02, 2017 1:20 am

greenleafvt wrote:I'm having some probems with Z sorting 3D files in Q3D. Even if I palace things on different layers they seem to have Z errors. Thought that the order creation would place them on top but no luck. Any ideas? Or am I missing something here. Tried Scirra z order, and Q2D sort order but they still display wrong.

Cheers,

http://www.liquid-glass.com/123/test.capx


I'm sorry to take so long to look at the .capx. I was out on vacation, and just got back today.

I noticed a few odd things:

1. You are creating 4 new objects every tick in the "MATRIX" event sheet. This makes it almost impossible to debug anything because it quickly drops the frame rate to a standstill. I put all four object creation events under a single "On Start of Layout" so that you only create them once.

2. You are placing each object in an unexpected way. They all have almost, but not quite, the same z position:
(500,500,1)
(500,540,2)
(500,580,3)
(500,620,4)
Given that each box is a 50 x 50 x 50 cube, did you really mean to space them 1 apart in the z-direction?

3. You don't need to create a new object type each time you want to place an object. I assume each of these should be an instance of the "crate" object, or something similar? If you want 4 of them, just use a for loop to create one and place it appropriately each loop. Or just drag them out onto the layout by hand. I place everything in my level using a top-down view, then position the camera so it looks at everything from a 60 degree angle.

If you are interested, I can send you a sample .capx showing how I would place things in the layout, then design the 2D UI on top of that.

Have you given any thought to how you want to design x-y coordinates? Do you want to place everything on a standard x-y grid, then move the camera so it is looking from an isometric perspective? Or do you want to place everything in an isometric grid to begin with? I haven't done an isometric game before, so I'm not sure how people typically lay things out. I suppose it primarily affects the mathematics of character movement...
www.simbucket.com - HTML5 Science Simulations / https://www.airconsole.com/#!play=com.n ... obotrumble - Robot Rumble on AirConsole
B
46
S
11
G
20
Posts: 363
Reputation: 14,199

Post » Fri Jun 02, 2017 10:24 pm

@fuego

Q3D Wasn't really designed with nested objects in .obj's in mind, Since this doesn't really fit with the workflow of Construct's picking system. Really you should have one Q3DModel for every static geometry. There's kind of no point working without constructs picking inside construct, and the advantage of using Q3D+C2 over javascript alone quickly disappears with lots of added overhead. Some Q3D things are redesigned from three.js to give speedup / avoid bad practices that would quickly ruin performance. I

@cjbruce

What do you mean by instancing?
B
75
S
13
G
8
Posts: 1,973
Reputation: 9,841

Post » Fri Jun 02, 2017 11:39 pm

QuaziGNRLnose wrote:
@cjbruce

What do you mean by instancing?


"instances" is a term used in babylonJS to describe identical 3D objects added to an array and rendered in a single draw call. I have been struggling with adding more than a handful of projectiles onscreen before frame rate drops, and was hoping that I was missing something in the way I was creating and handling the objects.

I'm also a little worried because I haven't really started populating levels with anything more than blocks. I assume that the best practice is to import the entire level as one big 3D model, correct?

One more question: I have created toy robots that consist of a body, 2 motors, and 2 wheels. The motors and whels are positioned on the body, and their rotation is controlled programmatically by torque applied to the wheels. I am setting the position of each wheel and motor in world coordinates, because I can't seem to correctly parent the rotating objects to the robot body and spin them in terms of local coordinates. Am I missing something here? I should be able to do this, shouldn't I? Setting position and rotation of all of the wherls and motors every tick is taking up a significant chunk of CPU time, and I need to figure out how to do things more efficiently.
www.simbucket.com - HTML5 Science Simulations / https://www.airconsole.com/#!play=com.n ... obotrumble - Robot Rumble on AirConsole
B
46
S
11
G
20
Posts: 363
Reputation: 14,199

Post » Sat Jun 03, 2017 12:09 am

@cjbruce

The issue seems to be with the use of physics more than with the rendering of objects. A scene without physics should take many many objects before it slows on any okay CPU.

It's probably a better idea to fake the movement by considering the entire car a single rigidbody and applying torques to that to emulate wheels. Using hinges on cylinders will lead to trouble getting a good contact patch and make the controls poor, as well as open up the possibility of wheels getting out of alignment. This will also be much less costly
B
75
S
13
G
8
Posts: 1,973
Reputation: 9,841

Post » Sat Jun 03, 2017 12:45 am

@QuaziGNRLnose
I hear you. And understand where you're coming from.

Just know that, nobody buys a sports car that is speed-limited because the manufacturer knows it's dangerous for you. It has always been up to the content author / developer to avoid bad practices that would ruin game performance. Just my two cents.

Still, I appreciate the coding efforts and the choices (sacrifices) that were made to make it work as solidly as it does today. Would have loved to hear some of your development anectdotes.
I don't need a better iPhone, I need to be better.
B
23
S
9
G
20
Posts: 67
Reputation: 11,736

Post » Sat Jun 03, 2017 2:03 am

QuaziGNRLnose wrote:@cjbruce

The issue seems to be with the use of physics more than with the rendering of objects. A scene without physics should take many many objects before it slows on any okay CPU.

It's probably a better idea to fake the movement by considering the entire car a single rigidbody and applying torques to that to emulate wheels. Using hinges on cylinders will lead to trouble getting a good contact patch and make the controls poor, as well as open up the possibility of wheels getting out of alignment. This will also be much less costly


Actually, what I wrote above isn't exactly true. I am using a separate set of 4 invisible cylinders for the physics movement, and just setting the rotation of the visible wheels and motors based on the angular velocity of the invisible drive wheels. I really like the way the robots drive, and it gives the game a good feel when you land on a ramp or hit the ground:

https://dl.dropboxusercontent.com/u/55106174/rrfpsbattlearenatest/index.html

Press "2" to switch from the electric tank to the laser tank to see a closeup of the motors and drive wheels.

My problem is that 4 of the "laser tanks" require 6% of the CPU time in the debugger just to handle the position and rotation of the wheel and motor "eye candy". I would like to put visual wheels and motors on the other robots as well, but I will quickly overload the CPU if I try to do this. I feel like I should be able to save some CPU cycles by parenting the wheels to the body and positioning/rotating them locally, rather than in world coordinates. I just can't seem to get this to work correctly.

Edit: You can see the "invisible wheels" on the electric tank. The laser tank uses these as well, but they are invisible for the laser tank. We aren't done with the 3D models for the electric tank yet, so the current model is just a stand-in.
Last edited by cjbruce on Sat Jun 03, 2017 12:34 pm, edited 2 times in total.
www.simbucket.com - HTML5 Science Simulations / https://www.airconsole.com/#!play=com.n ... obotrumble - Robot Rumble on AirConsole
B
46
S
11
G
20
Posts: 363
Reputation: 14,199

Post » Sat Jun 03, 2017 4:54 am

@cjbruce

I suggest doing away with the physics based wheels entirely, and making the cars spheres/blocks instead. This should significantly boost performance and is how most video-game cars are implemented. Im assuming you made the wheels invisible because they were acting strangely? I realize this is probably a big change to make but my experience tells me its the best way to go.
B
75
S
13
G
8
Posts: 1,973
Reputation: 9,841

PreviousNext

Return to Completed Addons

Who is online

Users browsing this forum: No registered users and 4 guests