Working on new scripting system.

BTM

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.

http://sketchyphysics2.googlecode.com/files/Breaking1.avi

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

Sgal

@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:

Sgt.A.Johnson

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

CPhillips

Its not exactly a joint but I am making the camera a lot better.

CPhillips

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.

http://sketchyphysics2.googlecode.com/files/density.avi

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.avi

Also 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.

Wacov

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...?)

CPhillips

@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

Wacov

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

CPhillips

SPIV will use 2.0. But dont expect it to be faster. The bottleneck is Sketchup rendering.

Wacov

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

Physicsguy1

What is the script for the teleporter like?

CPhillips

@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.

Wacov

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?

CPhillips

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
setEvent

Body events are
onStart/onEnd
onTick
onKey,onButton,onMouse
onTouch,onTouching,onUnTouch

Loops could potentially hang Sketchup. What are you trying to do exactly?

Wacov

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...

CPhillips

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.

Wacov

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

Physicsguy1

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?

CPhillips

I havent changed anything to make joints stronger. In fact I have been spending a bunch of time trying to figure out how to make a weaker kind of joint.

Wacov

Any news on release yet... nothing specific, but a couple of weeks? More that a month? Throw me a bone here