mwpowellhtx Posted March 27, 2016 Share Posted March 27, 2016 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... Quote Link to comment Share on other sites More sharing options...
mwpowellhtx Posted March 27, 2016 Author Share Posted March 27, 2016 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; }) Quote Link to comment Share on other sites More sharing options...
adam Posted March 27, 2016 Share Posted March 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
mwpowellhtx Posted March 27, 2016 Author Share Posted March 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
Wingnut Posted March 27, 2016 Share Posted March 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
Temechon Posted March 27, 2016 Share Posted March 27, 2016 Negative scaling inverses normals of the mesh... Be careful with it adam 1 Quote Link to comment Share on other sites More sharing options...
mwpowellhtx Posted March 27, 2016 Author Share Posted March 27, 2016 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... Quote Link to comment Share on other sites More sharing options...
Wingnut Posted March 27, 2016 Share Posted March 27, 2016 Yes, you can set the pivot point on the "field" parent. Field = group? *nod* Or, field = playing field? Still *nod*. Quote Link to comment Share on other sites More sharing options...
adam Posted March 27, 2016 Share Posted March 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
mwpowellhtx Posted March 27, 2016 Author Share Posted March 27, 2016 @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)? Quote Link to comment Share on other sites More sharing options...
mwpowellhtx Posted March 27, 2016 Author Share Posted March 27, 2016 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"? Quote Link to comment Share on other sites More sharing options...
Wingnut Posted March 27, 2016 Share Posted March 27, 2016 node->abstractMesh->mesh http://doc.babylonjs.com/classes/2.3/Mesh See "Description" Man, you're getting instantaneous assistance from 3 people! Wow! Quote Link to comment Share on other sites More sharing options...
mwpowellhtx Posted March 27, 2016 Author Share Posted March 27, 2016 @Wingnut I know, crazy right? Looks as though I could start from abstract mesh. Much appreciated all... Quote Link to comment Share on other sites More sharing options...
adam Posted March 27, 2016 Share Posted March 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
adam Posted March 27, 2016 Share Posted March 27, 2016 12 minutes ago, Wingnut said: Man, you're getting instantaneous assistance from 3 people! Wow! jerome, GameMonetize and Wingnut 3 Quote Link to comment Share on other sites More sharing options...
mwpowellhtx Posted March 27, 2016 Author Share Posted March 27, 2016 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); Quote Link to comment Share on other sites More sharing options...
adam Posted March 27, 2016 Share Posted March 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
Wingnut Posted March 27, 2016 Share Posted March 27, 2016 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? Quote Link to comment Share on other sites More sharing options...
mwpowellhtx Posted March 27, 2016 Author Share Posted March 27, 2016 @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. Wingnut 1 Quote Link to comment Share on other sites More sharing options...
mwpowellhtx Posted March 27, 2016 Author Share Posted March 27, 2016 @adam You still haven't said what it is you are talking about. Quote Link to comment Share on other sites More sharing options...
mwpowellhtx Posted March 27, 2016 Author Share Posted March 27, 2016 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. Quote Link to comment Share on other sites More sharing options...
mwpowellhtx Posted March 30, 2016 Author Share Posted March 30, 2016 The math is pretty simple to handle as contrasted with delegating to any scaling agents. And the result is much nicer. Wingnut 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.