Im going to post a better version of this tutorial tonight, where Ill do a version with a lot more solid explanation of the calculation in all three dimensions. And a way smoother system… Ill also do this one from scratch so you can follow along.
It’s actually best to avoid modifying what properties a class has after construction. Javascript engines can optimize classes (more details) if their property list doesn’t change. As soon as you add a property it becomes “deoptimized”.
I would recommend declaring these properties in the Script constructor and then storing them on the script instance. Like this:
can you explain that a little more in debth, I think I get what you are saying but it is kinda fuzzy… Um I think I may have fixed what you are speaking of later in the tut, because when you declare them like that it drops a whole bunch of errors!
Im almost positive on the first execution I go back and rename everything to correct conventions, I was just trying to keep the video flowing so I stopped thinking about some stuff like variable names. Thank you for watching it though, I will keep posting more when ever I have time. I will do some modeling and texture tutorials as well, and also how to port mograph generated animations into a baked FBX file that will work on pC.
Regarding JS Objects, when there is a “class” (function for instantiating objects) its fields (this.) will be “indexed” by VM, so behind the scenes it creates “Shadow Class” which is more optimised and precompiled for better performance. But every time you modify class fields, dynamically defining new fields then it does not uses previous shadow class, and makes a new one. This happens behind the scenes, but has good performance increase. So good rule is not to change class fields, or at least have few versions of it but stick to them.
Pretty much same rule applies to variable types - changing variable types on the fly (string to number), is not as good as having two variables in first place.
Hope that makes a bit more clear about the way VM works. There are some youtube talks about “behind the hood in JS”.
A playcanvas Entity is a “class” in javascript. That is, it is created like this:
var entity = new pc.fw.Entity();
Internally that calls the Entity constructor (and the base class, the GraphNode constructor). These look something like this:
var Entity = function() {
this._guid = pc.guid.create();
// more member variables...
}
The Javascript VM now knows that an Entity has a member called _guid plus any others that are declared in the constructor. It can make internal optimizations based on this assumption.
If you do this:
var entity = new pc.fw.Entity();
entity.anotherProperty = 123;
Then the VM can no longer use those optimizations because you have added a property.
In your case you’ve take a reference of the entity into this.cam then you add all your member variables to this.cam instead of this. It is more optimal to declare all the members you are going to need in the constructor:
var Orbit3d = function (entity) {
this.entity = entity;
//.. declare members here
};
Then use those in the rest of your script.
Like I said, it’s not massively important, but it will be more optimal. So it’s worth getting into the habit of it.
I’m sorry, will avoid replying to old posts in the future. I’m trying to learn and I really wanted to read through these tutorials. I suppose there aren’t any archives of old projects, are there?