Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark Physics & Dark A.I. & Dark Dynamix / [Dynamix] General feedback

Author
Message
Chris Tate
DBPro Master
11
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 13th Jun 2013 19:09 Edited at: 27th Jun 2013 03:30
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

Quote: "Parameters:
sourceTetFile - Name you wish to assign to the created file.
tetFile - Name of the .tet file you wish to cook the mesh from."


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)

Quote: "TRUE if succeeded, FALSE otherwise. NOTE: Will return false if mesh is currently in use.None"


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


Quote: "DYN TRIGGER GET STATUS() // entered, leaving, staying or mixture.

Help:
int DYN TRIGGER GET STATUS ()

Use this to retrieve which object has entered the trigger shape associated with the current trigger data.


"

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


Quote: "DYN RAYCAST HIT GET U () - DYN RAYCAST HIT GET V()"


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.

Matty H
11
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 18th Jun 2013 14:31
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.

Chris Tate
DBPro Master
11
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 18th Jun 2013 21:49
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.

Chris Tate
DBPro Master
11
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 25th Jun 2013 05:13
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)

Matty H
11
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 26th Jun 2013 14:06
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?

Chris Tate
DBPro Master
11
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 26th Jun 2013 17:54
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.

Chris Tate
DBPro Master
11
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 27th Jun 2013 03:28
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.

Login to post a reply

Server time is: 2019-12-08 00:16:09
Your offset time is: 2019-12-08 00:16:09