Working on new scripting system.
-
Just collision and only simple shapes (not compound). And it just works with contacts not stresses. I dont think it would be possible to do stress. Not sure if it will be in SPIV or SP3. There are a lot of problems with it right now.
I dont know the answers to the rest yet.
-
There is a big problem with the breaking feature. The actual breaking of the geometry is very slow. It can take several seconds to break a model.
Maybe it can be optimized somehow. But I am going to go back to the scripting stuff for now.
-
@cphillips said:
There is a big problem with the breaking feature. The actual breaking of the geometry is very slow. It can take several seconds to break a model.
Maybe it can be optimized somehow. But I am going to go back to the scripting stuff for now.
I would have guessed that. Maybe you can get sketchyphysics to figure out how to break the object at the start of the animation, then find the object's position and orientation on the collision and break it, or replace it with the broken pieces already made at the start, but not used. Just a thought, I don't have a clue how you're doing it currently, so I'm just throwing this out there
-
@wacov said:
With the teleportation, will the camera be moved if it's following a teleported object? And could you have a breakable object, which, when broken, teleports back to the starting position with all its joints intact?
To fix the camera problems I think the best would be a "camera" joint. I know that In other 3D programs they are commonly used. It would be more user-frendly,too.
This is what I mean:
-
So when the sim starts the camera moves into it and faces wherever the joint is facing right. Seems like a good idea if ive interpreted it right
-
Its not exactly a joint but I am making the camera a lot better.
-
The new scripting interface is making it much easier to expose the functionality of the physics engine. Full material support will have to wait until SPIV, but you can now change object density and linear/angular damping. That means you can have one object weight more or less than an identical object.
Orbital mechanics type stuff now works because you can set damp to 0.0. Or even set it high to make objects act like they are in quicksand.
http://sketchyphysics2.googlecode.com/files/orbit.aviAlso exposed is velocity and torque. You can make an object that starts in motion or rotating.
Teleporting is working well now. I tried to make a "portal" type object but it is proving harder than I expected.
-
All this stuff is SO awesome... when you say linear/angular damping, will that act like a basic kind of air resistance? And what I'm really interested in, is if you set density to 0, what happens? Is it truly 0... i.e no weight or inertia? As long as it works ok as a noCollision object, attached to something else, then it's fine. Then with the torque and velocity; can you set them at runtime? And can you retrieve the object's current torque and velocity?
And, out of interest, isn't it now possible, with a few workarounds, to copy/paste and emit complex (jointed) objects? Just automatically connect each object with script at the beginning of the simulation, and do the same thing with emitters (if we can set an emitted object's script field...?)
-
@wacov said:
All this stuff is SO awesome... when you say linear/angular damping, will that act like a basic kind of air resistance?
Yes
@wacov said:
And what I'm really interested in, is if you set density to 0, what happens? Is it truly 0... i.e no weight or inertia? As long as it works ok as a noCollision object, attached to something else, then it's fine.
No. For some reason the physics engine treats objects with very low mass as static. Thats why really small objects dont move. Its lame in my opinion but not something I can change.
Depending on what you need a zero mass object for there may be something that will do what you want. I havent got it working yet but there is a new script command that will let you say where you want an object to be and it will "fly" to that location with out any sort of joint.
@wacov said:
Then with the torque and velocity; can you set them at runtime? And can you retrieve the object's current torque and velocity?
Yes.
@wacov said:
And, out of interest, isn't it now possible, with a few workarounds, to copy/paste and emit complex (jointed) objects? Just automatically connect each object with script at the beginning of the simulation, and do the same thing with emitters (if we can set an emitted object's script field...?)
Its possible. Objects that connect themselfs at start or on touching will work like that. But so far it still requires a lot of fiddly scripting. Not sure how it will turn out in the end.
I haven't exposed the emitters to the script yet. But you can do almost the same thing using the copy command.
Here is a simple teleport:
http://sketchyphysics2.googlecode.com/files/teleport2.wmv -
I suppose you can set velocity and torque to 0 when teleporting? So, it doesn't always have to come out with the same momentum?
All this is really cool... I think you're gonna run out of features for SPIV
EDIT: Are you going to switch to Newton 2.0? I understand the beta is out... multi-core and speed optimizations sound tantalizing
-
SPIV will use 2.0. But dont expect it to be faster. The bottleneck is Sketchup rendering.
-
I'm optimisticly expecting improvements in Su's rendering, given the topics of the last survey... but that's just silly ol' me
. Multi-core certainly seems to be expected, so maybe all's not lost -
What is the script for the teleporter like?
-
@unknownuser said:
What is the script for the teleporter like?
setEvent("ontouch"){|toucher,speed,pos| if(toucher.name=="ball") toucher.teleport(toucher.position+[-500,0,0]) end }When the object is touched by something named ball, teleport that object -500 in the X direction.
-
Is the delete command just '.delete'? Could you give us a breakdown of all the attributes/methods attached to the curEvalGroup class in the next version (assuming that's where '.position' now comes from). Oh, and I was wondering, how do you loop a block of code in Ruby, within a single frame, until the target is acheived?
-
You mean to delete a body? Its actually called "destroy". curEvalGroup will not be used in the new scripted field, its implied. Currently bodies have the following:
magnetic/solid/static/frozen
position/transformation
getVelocity/setVelocity
getTorque/setTorque
teleport
push
copy
destroy
connect/attach
split
setEventBody events are
onStart/onEnd
onTick
onKey,onButton,onMouse
onTouch,onTouching,onUnTouchLoops could potentially hang Sketchup. What are you trying to do exactly?
-
The pathfinding algorithm needs to run through a loop of a series of steps to find the path. The loop ends when the target is added to the closed list OR there are no Nodes left on the open list. I could always stick in a failsafe to carry it over to the next frame after a certain number of loops... be aware I'm not actually doing anything right now, I'm waiting for the next version
. I've got plans that use the new features... -
That doesnt sound like something you would want to do at runtime. Only when you actually move the nodes.
I think your node system will be easier with the new scripting system.
-
I HAS to be at runtime... the basis of any AI system is dynamic pathfinding. It'll re-calculate a route every time the target changes... anyway, if it crashes, I'll try something else
This explains it better that I can: http://www.policyalmanac.org/games/aStarTutorial.htm -
Quick question for Chris Phillips: I saw one of the videos that you posted, that demonstrated the new joint-connect script. As I recall, the connection looked much stronger than the current joint connections. Is this true?
Advertisement