Sorry your browser is not supported!

Dark Basic Professional Dynamix Feedback

I will be using this tool for the next year, so I will post feedback here quite often.

Do what you like with it, much of this is just me reminding myself if anybody of the gotchas and techniques; but for what it is worth it may be good for tracking performance and issues.

Issue 1
User function 'DYN MAKE CAPSULE ' must return a value if used in an expression at line 15630.

This is supposed to return true if the command succeeds; but either the documentation is wrong or the function isn't 100%.

Issue 2
In addition, the DYN COOK SOFT BODY MESH command states it should return a boolean in the documentation ; but this is not so.

Issue 3


This DYN COOK SOFT BODY MESH overload does not accept two strings; I tried to play around but couldn't figure out what parameter is missing. I ended up looking at your example but that uses the first overload.

May I ask, is this another way to create .TET files? The PhysX SDK for some reason will not extract due to an invalid windows 32 bit application error raised by the setup program.

Issue 4
bool = DYN SOFT BODY MESH EXISTS(id)

This function does not work in DBPRO. The compiler expects no parameters; the compilation succeeds when the parameter removed.

Issue 5
DYN MAKE SHAPE BOX (int objectID, float density)
DYN MAKE SHAPE SPHERE (int objectID, float density)
Documentation states these should return true if it succeeds; that is not the case. These compile as voids.

DYN MAKE SHAPE CAPSULE, DYN MAKE SHAPE CONVEX, DYN MAKE SHAPE TRIANGLE MESH All successfully compile as returner functions

Issue 6
DYN DELETE CLOTH MESH (int clothMeshID)



This is not the case in DBP; the compiler sees this as a void function; no returned value is expected.

Issue 7
result = DYN COOK CONVEX MESH(ob)
result = DYN COOK SOFT BODY MESH (ob)
result = DYN COOK TRIANGLE MESH(ob) {To mesh, not to file}
result = DYN COOK CLOTH MESH(ob)

These are all registered in DBP as void functions, but documentated as boolean functions.

Issue 8
DYN DELETE FF LINEAR KERNEL
DYN DELETE FF SHAPE GROUP

These force field commands are documented as parameterless functions. They require an ID parameter.

Issue 9
e = DYN MAKE FORCE FIELD()
e = DYN MAKE FF LINEAR KERNEL()
e = DYN MAKE FF Shape Capsule()
e = DYN MAKE FF Shape Group()
Also: e = DYN MAKE MATERIAL ()

These functions are documented to return true if the call succeeds, however they are registered as voids; they return nothing.

One force field creation function which does return a result is the DYN MAKE FF SHAPE CONVEX( iPosVec, iAngleVec, iSizeVec) function

Issue 10
iResult = DYN MAKE WHEEL ( ob, fDensity# )
iResult = DYN MAKE TIRE FUNC DESC ( id )
result = DYN UPDATE SOFT BODY DEBUG(ob, iSoftBody)
These functions are documented to return true if the call succeeds, however they are registered as voids; they return nothing.

Issue 11
result = DYN MAKE SHAPE TRIANGLE MESH(ob, iLimb, iMesh) {Second overload}
This limb oriented overload will not run; even though the compile will succeed. The following error is thrown:
The current work around is to use an object as a reference rather than a limb.

Issue 12
DYN RAYCAST HIT GET DISTANCE()

This function is not recognized by the runtime, which is quite unfortunate being an important command. The command itself is compilable; but it will cause a runtime error. There is no way to get the raycast distance that I can see. At least the get raycast object and world hit location commands work and can be used to work out the distance instead.

Note that the Raycast example features semi-colons at the end of lines. Not really DBP syntax.


Issue 13


In this case the documentation is wrong. This function returns the flag indicating what occurred; not the object index.

Issue 14

The RayCast demo does not work. The group flag parameters seem to prevent it from working. I can't seem to get any kind of flag to work without incorrectly hitting all or no objects.

One thing for learners to watch out for is the direction vector needing to normalized; which isn't mentioned in the documents, EG: -1.0 to 1.0 per axis. 0,0,1 is forward, 0,0,-1 is backward. 1,0,0 is right and -1,0,0 is left. Matrix1 utilities has the VECTOR3 DEGREES TO VECTOR and VECTOR3 VECTOR TO DEGREES functions for this.

Issue 15



These commands are not recognized by the runtime. They successfully compile, but cause a program error.

FEATURE REQUESTS

Feature requests I make are simply ideas. There may be good reasons to not include them; but it is useful to make note of what seems to be missing.

1 Ray casts with object exclusion parameter. For example: No need for a laser beam to test collision with itself; current object group flags don't work; and even if they did, sometimes the object casting the ray is in the same group as the objects being raycasted at.

2 Dyn Raycast Object( ObjectID, Position, Direction ) OR Dyn Intersect Object( ObjectID, Position, Direction ). I am finding it OK to store all the possible raycasts during the Data retrieval loop; but sometimes elsewhere in the program I hit a situation where, 'damn I wish I could check if ObjectA can see ObjectB using PhysX hardware'; no consideration for all the other objects in the map; just this one object only.

3 Minor request. Since returning vectors are so effective, it would be nice to be able to optionally do things like DYN SET LINEAR VELOCITY int objectID, int vectorID.

Thanks Chris, I will reference this post when I get around to the update.

There seems to be many issues regarding return values, when developing this I took the approach that functions which return a value as extra information(but not necessary) also have a 'void' version since DBPro forces you to use(assign) the returned value even though you may not want it, I found that a little annoying.

I thought that was the case. It would be useful to know if functions succeed; if it is possible for them to fail for some reason, at least from my standpoint. But the void method is good for speed and ease of use I guess.

No rush at all really, at least by the time you get round to the update; I will have made a decent test of all of your functions and will have all the issues listed here so that there is no guessing where problems are.

Just a question when you get time; no rush. Is this the best way to resize a trigger object during the simulation?



Supposing the trigger is an area of effect element that grows over time; I figured I'd need to scale the object up, fix the scale then recreate the actor. (Not pretty, but there is no scale command that will update the shape)

PhysX does not allow shapes/actors to be scaled in real-time so the way you are doing it seems to be the best way.

Have you tried keeping the object and just hiding it, rather than deleting it? Since the object can be scaled it should save some processing, you would then just delete the actor and make it again from the same object with its new size?

I'll give that I go. I'll let the benchmark tests indicate where things need speeding up; I'm not yet sure if my game will need to scale such triggers frequently.

Thank you for using vector return values; what a time saver. All DBPRO 3d commands should have had vector overloads really; so glad you did it. I've added a very low priority request for vector input parameters.