Odd looking after-scaling issue

[mwpowellhtx]

Hello,

I've got a strange looking render order issue. The "original", non-scaled object(s) appear fine. They render correctly as I might expect. See before-scaling image.

However, I applied a scaling about the Z axis (new Vector3(1,1,-1)), and it got all wonky. Almost like the render order was out of wack. See after-scaling image.

How do I tell the scene which order to render? Or better yet, how to group them so that it's a non-issue?

Thank you...

[mwpowellhtx]

For reference, I am doing something like this to apply my scaling, but honestly, I do not know how that would be any different? This is not any different when I set the default identity; only with the Vector3(1,1,-1) I get the odd rendering issue.

/* this is my GoalPost model replete with calculations for points etc. */
this.children = [
    this.post
    , this.padding
    , this.arch
    , this.crossBar
    , this.leftUpright
    , this.rightUpright
];

/* gets the scaling obtained from GoalPost; set, or "default" to "identity", or Vector3(1,1,1) */
var scaling = this.getScaling();

/* each() is an extension method I attached on Array.prototype. */
this.children.each(function (x) { x.scaling = scaling; })

 

[adam]

1 hour ago, mwpowellhtx said:

Or better yet, how to group them so that it's a non-issue?

childMesh.parent = parentMesh;

You can use an empty mesh as a container too.

[mwpowellhtx]

1 minute ago, adam said:

childMesh.parent = parentMesh;

You can use an empty mesh as a container too.

Thanks for the tip. That's secondary to the rendering issue, but I am concerned this might be a little deeper than gathering meshes in a JavaScript array.

[Wingnut]

Hi guys!  *nod*  Negative scaling... that's unhealthy.  That's been known to make mesh do strange things.    We lost a forum user one time, when he accidentally used negative scaling values, and his computer room turned inside-out.    Try to avoid using negative values for scaling (unless you are a mad scientist who likes torturing webGL).

To add-on to Adam's fine-but-short answer:

var parentMesh = new BABYLON.Mesh('groupwidget', scene);  (how to make an empty mesh to use for all children.parent).  Pretty easy.  You can still maintain a list of parentMesh.children[] but make sure you iterate thru them... and set each.parent = parentMesh; 

We also have a "tags system" that let's you do some fancy wildcard-match "gathering" of specific tag-groups from the scene.meshes array.

[Temechon]

Negative scaling inverses normals of the mesh... Be careful with it

[mwpowellhtx]

This sort of scaling works just fine rendering from Helix Toolkit for WPF. Probably an unfair comparison, I'll grant you.

@Wingnut Avoidance is fine, fair enough; but do you have any suggestions? Being the lazy developer that I am, I want to calculate things smart, ONCE.

@Temechon Obviously. Suggestions?

If I were to establish a non-zero field origin, let's say, is there a method that transforms or "rotates" about a non-zero origin, for instance?

Thank you...

[Wingnut]

Yes, you can set the pivot point on the "field" parent.  Field = group?  *nod*  Or, field = playing field?  Still *nod*. 

[adam]

24 minutes ago, mwpowellhtx said:

Thanks for the tip. That's secondary to the rendering issue, but I am concerned this might be a little deeper than gathering meshes in a JavaScript array.

What array?

You then scale the parent and it scales all the children.

Parenting is how you group meshes in BJS.

[mwpowellhtx]

@Wingnut At the moment, yes, "field" is the parent object, with goal posts on one end (original), and another, to be modeled, then "rotated".

Currently, I assume absolute origin (0,0,0) is center/center field, if you will; all the calculations for goal posts, lines, etc, just work out real easy.

But if I were to calculate relative to world (or field) origin, wouldn't be much different, I expect.

So, what's the BABYLON primitive(s)?

[mwpowellhtx]

1 minute ago, adam said:

What array?

You then scale the parent and it scales all the children.

I see; my "parent" is not a mesh object, per se; it's just a calculator, per se, with some mesh children captured in a prototype variable. Does that make sense?

If possible, yes, I might like to "extend" a mesh prototype. "Base class"?

[Wingnut]

node->abstractMesh->mesh 

http://doc.babylonjs.com/classes/2.3/Mesh

See "Description"

Man, you're getting instantaneous assistance from 3 people!  Wow! 

[mwpowellhtx]

@Wingnut I know, crazy right?

Looks as though I could start from abstract mesh.

Much appreciated all... 

[adam]

11 minutes ago, mwpowellhtx said:

If possible, yes, I might like to "extend" a mesh prototype. "Base class"?

parent is just a property of mesh.  You won't be extending the base class.

[adam]

12 minutes ago, Wingnut said:

Man, you're getting instantaneous assistance from 3 people!  Wow! 

[mwpowellhtx]

9 minutes ago, adam said:

parent is just a property of mesh.  You won't be extending the base class.

Of course I would. Why wouldn't I? For example,

// Mesh, or possibly even AbstractMesh, if I dared...
Element.prototype = Object.create(BABYLON.Mesh);

 

[adam]

25 minutes ago, mwpowellhtx said:

Of course I would. Why wouldn't I? For example,

You are talking about one thing and I am talking about another.  I'm leaving.

[Wingnut]

hahahaha.  Adam, you're too funny!

But yeah, I am starting to think that @mwpowellhtx is... umm... a mad scientist. 

There are two types of people in the world.  #1 - Those that follow the direction of the big neon arrow.  #2 - Those that disassemble big neon arrows... to discover what makes them point.

I suspect that mw is a type #2. 

By the way, would you like to learn the "down and dirty" way to move pivot points?

Move mesh sideways 20 units.
mesh.bakeCurrentTransformIntoVertices();
move mesh back to origin

Done.  mesh now has an offset pivot point.  Fun, huh? 

[mwpowellhtx]

@Wingnut You're on the right track; I like to kick the tires a bit. When I can teach it back to you, then I have mastered it. 

[mwpowellhtx]

@adam You still haven't said what it is you are talking about.

[mwpowellhtx]

It's turning into a bit of a rabbit hole, which is fine is this is the right way to go about it. I bumped into a couple of errors needing to fill in some gaps, such as getTotalVertices, isReady, isEnabled; all fairly benign, it would seem.

Element.prototype.getTotalVertices = function() {
    return this._children.sum(function (c) {
        return c.getTotalVertices();
    });
}

Element.prototype.isReady = function() {
    return this._children.all(function (c) {
        return c.isReady();
    });
}

// perhaps should be connecting with children?
Element.prototype._enabled = true;

Element.prototype.isEnabled = function() {
    return this._enabled;
}

Element.prototype.setEnabled = function (state) {
    this._enabled = state || false;
    return this;
}

However, now I am stumped on a computeWorldMatrix, which I haven't got a clue about, except to say, that instead of keeping track of _children, per se, perhaps I should be using the BABYLON.Mesh.MergeMeshes function in order to merge the parts of my models into a single cohesive mesh.

So, first assumption, that I should inherit from BABYLON.Mesh? Yes, no, maybe?

And/or if not, then how else?

With the backdrop being the odd looking scaling going on. That's before jumping into any world coordinate systems, which maybe I need to do anyhow.

[mwpowellhtx]

The math is pretty simple to handle as contrasted with delegating to any scaling agents. And the result is much nicer.