BJS Camera and Scene

[max123]

Hi,

I hava a question/suggestion re BJS Cameras/Scenes. 

1) In THREE.js a Camera inherits all 3d properties from a Node, including Scale, which is VERY handy: by changing the scale of camera, you're changing the World's scale. 

2) Same applies to a Scene: you can simply state myScene.scale.x = 2 and it works beautifully!

Now, maybe I'm missing something in BJS, but what do I do if I need to scale an imported Scene? Iterating through meshes seems like an awkward way of doing things - same as creating an empty parent for all objects in the scene. Is there a simple solution?

3) Are there any helper objects in BJS, e.g. light cones, floor grids etc?

Thanks.

[GameMonetize]

Hello!

1 and 2. To scale a group of meshes (or all of them), you only need to make them child of a root mesh that you can create.

Here is a pseudo code:

var root = new Mesh();
for (var index = 0; index < scene.getMeshes().length; index++) {
  var current = scene.getMeshes90[index];

  if (!current.parent) {
   current.parent = root;
  }
}

root.scaling.x = 10;

3. We have a grid material: http://doc.babylonjs.com/extensions/Grid and we can create cone  (

)

[Wingnut]

Phew, thanks for answering this one @Deltakosh.  It scared me.    To add-to DK's comments, Babylon.Tools has a few good helpers, but I don't know why showAxes and showNormals were never added, there.  Maybe nobody "gave" them to our team (yet).  *shrug*

ANYway... here they BOTH are, in one handy playground demo.  http://www.babylonjs-playground.com/#1KN1LB#39

ShowUVS(), CreateLightGizmos(), CreateCameraGizmos()... all could be good helpers.  Use LinesMesh for all of it, huh?  I think LinesMesh are lightweight and won't add much load to a scene... when they are turned-on.  Wireframe-like shapes/gizmos.  Yeah. 

In fact, hey @max123... why don't you become the custodian/God of helper-things... for our team?  Can ya?  Would ya?  If you became a custodian of Babylon.Tools... you get special privileges... such as working harder than others, and answering forum questions about the tools collection.  Good fun! 

Want to know what the #1 helper-feature for BJS is?  (I knew ya did.)  It's the playground itself. 

But see that "Debug layer" button at the top of the playground?  That... is the #2 helper thing.  It's wonderful.  It has rescued me MANY times.

That scale-camera and scale-node and scale-scene stuff... that is all just weird.  (no offense, max, it's still an interesting thought).  I got a tumor thinking about it, and could not answer.  It was too weird. 

One might wonder if scaling the worldMatrix...  and the viewMatrix... and the projectionMatrix... hmm... never mind.  I'm not qualified. 

[max123]

@Deltakosh, thanks - that works.

[max123]

@Wingnut, I can sense a pinch of good-natured irony in your reply. I would love to help, but being mathematically challenged, my direct involvement would probably spell doom for BJS

Whilst we're on the subject, is there a way to assign mouse wheel + pinch-zoom to ArcRotateCamera's fov? For example, I'm working on a project where the camera is at the centre of the scene. I set upper and lower RadiusLimit to 1 and would like to replace the default wheel/pinch-zoom attached to radius with fov.

[max123]

btw, love this community. In a lot of places they call you a wanker for making suggestions or asking "silly" questions

 

[GameMonetize]

@Wingnut, regarding this PG ( http://www.babylonjs-playground.com/#1KN1LB#39 ). I'm completely ok if someone wants to integrate these helpers in the toolkit

@max123: Don't be scared, there is always a first PR, then things become easier

[Pryme8]

https://github.com/Pryme8/TOWER/blob/gh-pages/js/tower.widgets.js

This might help some with widgets as well.
- Horizon
- Grid
- World Axes
- Local Axes
- Position
- Rotation
- Scale

the script might look a little odd, cause its tailored for my editor... but it does draw all the widgets once and then stores them and reuses them so there is minimal impact.

[Wingnut]

Yeah, it would be great to put a bunch of minimum-scene-load tools... in the 'toolkit'... but I'm too weak with .ts, and besides, that's all too scary for me.    I'm of better use... whining about it until someone qualified does it for us.  You know, someone who can edit the "What's New?" list, too.  (yeah, I know, anyone can edit THAT, too.  shhhh)

Ok, back to this camera patch panel thing.   Max wants to detach the mousewheel from the arcCam .radius, and attach it to the arcCam .fov.  Patch cord change!  I have no idea how to do this... but I thought I would remind everyone of the current issue.

And yes, Max, I was razzing you a bit and being goofy.  But still... scaling node, scene, camera, or even light... non-mesh stuff... that's interestingly weird.  It sort of blows my mind.

Almost like... Scene object.... would have an AbstractMesh "attached' to it... and if we scale IT... the whole scene scales... including the distances of things from origin.   I can see why .fov is the next best choice... for doing things like this.

Can you imagine... your player finds a bejeweled box on the ground, opens it, and discovers 4 BJS scenes inside... complete.... just miniaturized?  Player grabs one, drops it into the Expand-o-Matic, and boom... he's a player in THAT scene.  Fun!   But, you know, it is probably wiser to make those 4 scenes in the box... be little godray'd chrome gems... and you can STILL drop them in the expander (which is now... actually a Scene object manager)... and still visit the new scene just fine.  Fun!  Weird. 

[Nabroski]

What is happening here?

http://threejs.org/docs/#Reference/Cameras/PerspectiveCamera

you have to resize the engine
http://doc.babylonjs.com/classes/2.4/Engine

you have to make you own input in babylonjs https://doc.babylonjs.com/tutorials/Customizing_Camera_Inputs
to detach the mouse wheel event from a oberver etc trigger

or use the javascript event handlers, 

http://www.babylonjs-playground.com/#TVP56#0

edit you already in changing the the fov mod .... perdefault
http://www.babylonjs-playground.com/#LYWVE#0

 

[Pryme8]

ts scares me.

[dbawel]

On 8/24/2016 at 4:13 AM, max123 said:

1) In THREE.js a Camera inherits all 3d properties from a Node, including Scale, which is VERY handy: by changing the scale of camera, you're changing the World's scale. 

I hope you're referring to only scaling the camera position and/or changing the orientation of cameras, lights, etc, only based upon world space coordinates. And as mentioned above, parenting can easily handle all of the above. It should even be very simple to write a function to handle all of the parenting relationships within the BJS framework to make this a single step.

However, if you're looking to affect atrributes such as scaling the aspect ratio of the camera output or other rendering attributes, then I wouldn't personally want to see anyone working with cameras in this way. But that is simply my own personal preference, as I see far too many issues with adding this type of functionality in altering standard scene objects based upon changes in the world space coordinate system. This would quickly introduce serious problems inherent with proceedural changes to key objects which are rendering reliant. But I'll assume I'm overthinking your goals for the end result.

Otherwise, have at it, and enjoy.

Cheers,

DB

[max123]

@Nabroski that works great, thanks!

[max123]

17 hours ago, Wingnut said:

Can you imagine... your player finds a bejeweled box on the ground, opens it, and discovers 4 BJS scenes inside... complete.... just miniaturized?  Player grabs one, drops it into the Expand-o-Matic, and boom... he's a player in THAT scene.  Fun!   But, you know, it is probably wiser to make those 4 scenes in the box... be little godray'd chrome gems... and you can STILL drop them in the expander (which is now... actually a Scene object manager)... and still visit the new scene just fine.  Fun!  Weird. 

Bending reality is fun!

[max123]

Don't hate me, but I'm going to throw in another suggestion re cameras

It's purely to do with logic. Currently, all Cameras in BJS incorporate things that are not strictly speaking camera's functionality. To me, it would make sense if a Camera was just that: a representation of a real world camera. The way it moves around shouldn't be a part of the Camera class, but rather put in a sub package, e.g. camera.controls

A camera is a camera, you can put it inside a mobile phone, a dedicated camera box, or on a dolly

By way of separating camera's functionality and its movement around the scene, we would make it a lot more extensible: a movement class, e.g. ArcControl, would take care of it. I'd rather extend ArcControl than create another ArcControlCameraWithaZoomInsteadOfRadius

Hope it makes sense.

[max123]

17 hours ago, Wingnut said:

And yes, Max, I was razzing you a bit and being goofy.  But still... scaling node, scene, camera, or even light... non-mesh stuff... that's interestingly weird.  It sort of blows my mind.

Ever seen Alice in Wonderland?

[max123]

@dbawel, good points. I think it all boils down to how the engine was envisaged in the first place: if everything extends an Object3D which has position, rotation and scale properties (as is the case in the real world), then my perception of reality (I'm the Camera here ) will also depend on my relative size, position and rotation. My math / trig sucks, that's why I always try to find an analogy