Comments (16)
There is now a tag for the new 0.7.4
.
https://github.com/Mugen87/yuka/releases/tag/v0.7.4
from yuka.
I think you can share them right here in this issue.
Ok, here they come:
- class
Triangle
is undefined (reference here).
I mitigated by defining an interface as such:
export interface Triangle {
/**
* The first vertex position.
*/
a: Vector3;
/**
* The second vertex position.
*/
b: Vector3;
/**
* The third vertex position.
*/
c: Vector3;
}
Where in yuka
should this be placed?
-
OBB states that it wants a
rotation: Quaternion
for constructor andset()
while in fact is using aMatrix3
. This should be changed.
Lines 50 to 52 in 031df15
Lines 79 to 82 in 031df15
-
OBB param comment is invalid, should be
obb
instead ofaabb
.
Lines 602 to 603 in 031df15
-
MathUtils.clamp()
min and max are named wrong:
Lines 88 to 93 in 031df15
same hereLines 124 to 128 in 031df15
and hereLines 137 to 141 in 031df15
-
There are several nullable props in
HalfEdge
which denote per jsdoc that they are not.
See: https://github.com/Mugen87/yuka/blob/031df15b4990db59a294d3ecfb6543474b027aed/src/math/HalfEdge.js
The following are all nullable: next, prev, twin, polygon. -
All
graph
properties in allsrc/graph/search/*.js
are in fact nullable (as initialized with null) but state that they are not. -
All properties in
src/fsm/StateMachine.js
are in fact nullable (as initialized with null) but state that they are not. -
MeshGeometry.indices
is nullable
These are the ones that I could reconstruct.
If you agree on above points and clearify how you want it, I could create a follow up PR which changes these.
from yuka.
Types added as DefinitelyTyped/DefinitelyTyped#52724
from yuka.
You don't have to, it should be sufficient to add the following anywhere in the same file.
This transports the information of the expected shape without creating "real" code.
Nice! Did not know this was possible. 3d0aefc
from yuka.
Okay, all nullable properties should now be documented correctly 👍 . 2e2d1bd
from yuka.
For the record, the types have just been published as: @types/yuka.
If anyone want's to improve, feel welcome to become co-maintainer.
from yuka.
I think I would prefer to add the missing return this
statements. Do you mind creating a PR?
I just created typescript definitions for all types in yuka (I wonder if I should submit them as PR here)
Many thanks for this! According to my experience with three.js
, I suggest to add these types to https://github.com/DefinitelyTyped/DefinitelyTyped.
from yuka.
I think I would prefer to add the missing
return this
statements. Do you mind creating a PR?
See #44
I just created typescript definitions for all types in yuka (I wonder if I should submit them as PR here)
Many thanks for this! According to my experience with
three.js
, I suggest to add these types to https://github.com/DefinitelyTyped/DefinitelyTyped.
I had a quick glance at the README over there and might give it a shot.
I think to do so, we would be in need of releases/tags, in this repository won't we? Otherwise it is a pretty hard choice for me to decide when update of types is needed.
I mean, we are currently on 0.7.3 but which commit is it? three.js has proper tags.
Another possibility would be to convert the code base entirely to typescript and recompile it to es6 but I guess you would not want that.
While doing the conversion, there were some discrepancies I noticed (sadly I forgot to write them down as I was in a hurry), would you prefer to receive separate tickets on each of these?
from yuka.
I guess I have to start using tags now 😅 .
Another possibility would be to convert the code base entirely to typescript and recompile it to es6 but I guess you would not want that.
No, sorry.
While doing the conversion, there were some discrepancies I noticed (sadly I forgot to write them down as I was in a hurry), would you prefer to receive separate tickets on each of these?
I think you can share them right here in this issue.
from yuka.
I have quickly fixed point 2, 3 and 4 (8fdd2a9). However, I am not going to create a separate class for the inline type Triangle
.
The JSDoc for nullable properties would look like so, right?
* @type {HalfEdge | null}
from yuka.
I have quickly fixed point 2, 3 and 4 (8fdd2a9). However, I am not going to create a separate class for the inline type
Triangle
.
You don't have to, it should be sufficient to add the following anywhere in the same file.
This transports the information of the expected shape without creating "real" code.
/**
* A triangle shape used in {@link Ray#intersectTriangle}.
*
* @typedef {Object} Triangle
* @property {Vector3} a The first vertex position.
* @property {Vector3} b The second vertex position.
* @property {Vector3} c The third vertex position.
*/
The JSDoc for nullable properties would look like so, right?
* @type {HalfEdge | null}
Yes, this is correct.
However, I think some of the properties should become mandatory.
Sadly the serialization feature currently prevents us from doing so for many properties.
i.e. every Goal
needs an owner
, doesn't it?
However, the property is nullable, because of the constructor must be callable without arguments and therefore the object is theorethically without parent for some cycles (until foo.resolveReferences()
has resolved the entity).
To make things worse, the value owner
can in fact be a string
(for the time in between .fromJSON()
and .resolveReferences()
).
IMO the serialization/deserialization should be implemented with dedicated classes instead of baked into the concrete classes.
This is already half the case for every registerType
handling.
Would you mind me refactoring it out into separate classes?
Side effect of more cleaner code would be that the classes will also shrink when built into applications due to tree shaking, as the serialization would only be included when explicitly used vs. always as is the current case.
from yuka.
IMO the serialization/deserialization should be implemented with dedicated classes instead of baked into the concrete classes.
In three.js
we have followed a more centralized approach for serializing/deserializing however this leaks component related logic to external entities (e.g. ObjectLoader
). Hence, it was considered to introduce fromJSON()
and toJSON()
methods in all related classes similar to Yuka (see mrdoob/three.js#11266). I guess I want to keep this approach since it's in my opinion the more clear way. Even it means slightly larger bundles.
from yuka.
IMO the serialization/deserialization should be implemented with dedicated classes instead of baked into the concrete classes.
In
three.js
we have followed a more centralized approach for serializing/deserializing however this leaks component related logic to external entities (e.g.ObejctLoader
). Hence, it was considered to introducefromJSON()
andtoJSON()
methods in all related classes similar to Yuka (see mrdoob/three.js#11266).
The issue is still open and I fail to see a definitive answer there, as Don McCurdy (intentionally not linked here, did not want to cause a notification) pointed out, a factory is needed to create the instances properly.
However, it does not end there, as the dependencies are not ordered and in fact, can be circular in yuka (hence the *.resolveReferences()
methods.
I guess I want to keep this approach since it's in my opinion the more clear way. Even it means slightly larger bundles.
Larger bundles were not my main concern but rather the non strict types for properties as mentioned above.
Another solution would be, to add static fromJSON()
methods to the prototypes that resolve lazy.
That way, only the constructor must be registered (already the case on the various classes) and a static method must be defined on the prototype. This would make the fromJSON()
method a little more complex but allows strict types everywhere.
Furthermore, all shipped classes (GameEntity
, MovingEntity
etc.) would also have be registered and would not be special cases anymore.
However, I see that this is a pretty large change and will put it to rest for the moment. Maybe I will throw together an alternative example in the future.
from yuka.
I've investigated the nullable issue a bit more. Instead of adding | null
, it should be sufficient to add the question mark as a prefix. According to the docs:
This indicates that the type is either the specified type, or null.
Do you see any issue with that approach? If not, I would like to adapt it since the JSDoc generator will create a nice nullable
annotation in the HTML (similar to readonly
).
from yuka.
I don't see any problem with that as it appears that in jsdoc ?Foo
appears to be syntactic sugar for null | Foo
(or Foo | null
respectively) so it both means the same.
In the end, we only need to ensure/annotate that we do not allow undefined
here.
from yuka.
the types have just been published as: @types/yuka.
@discordier How does it work? Do the types get compiled from the source JSDocs? Or maintaining both by hand?
from yuka.
Related Issues (20)
- WanderBehavior within Navmesh HOT 2
- Efficient way to find an intersection HOT 2
- Steering handling in `Vehicle.update()` ignores `GameEntity.maxTurnRate` HOT 4
- how to judge arriveBehave over HOT 1
- how to set initial mesh HOT 1
- Request: Pathfinding 3D HOT 4
- Yuka and Babylon.js HOT 5
- Building navmesh HOT 2
- Question: Best Practices HOT 2
- Question: NavMesh HOT 8
- Non-terminating while loop HOT 5
- Is there any way to add obstacles dynamically on a 2D grid? HOT 3
- Building with webpack and es6 modules HOT 5
- SteerBehavior - Vehicle facing the wrong direction HOT 3
- How to generate NavMesh automatically? HOT 3
- NavMeshLoader for Typescript throw reference error for fetch HOT 1
- need explanation for this formula HOT 4
- YUKA findPath is not detecting any collisions in Babylon.js HOT 3
- Pursuit Behavor duplicate gltf model HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from yuka.