Working on new scripting system.
-
Did you split that manually, or was it randomly split at the initiation of the simulation? And if you did figure out the script that splits an object, can you control the breaking force, if possible?
-
I wrote a script that splits an object N times and I call it from the new OnTouch event. So it is "broken" at collide time. Right now it is a totally random shatter rather than splits at the point of contact. But I might be able to make it to a more realistic now that OnTouch now has info about how fast and exactly where bodies collide.
The other problem is the pieces don't inherit the movement of the original object. So that big box drops to the floor, stops on a dime and shatters, and then slowly falls to pieces. I need to figure out how to give the pieces velocity and rotation.
-
Ok, that's REALLY awesome... first, does it split the actual geometry, or the collision mesh? And one important thing would be efficiency; would we be able to set the generated pieces to noCollision, and delete them after a timer? Or better yet, create the biggest pieces normally, but on a deletion timer, and make the smaller pieces noCollision.
And I'm pretty sure it won't, but will it break in response to tension and/or internal stress? For example, putting a heavy weight in direct contact, without dropping it, or hitting it with an extremely powerful magnet.
-
That looks so cool, can't wait. But I have a question is this version going to still be sp3 or is it going to be spIV? Are we going to be able to control how many places the breakable script breaks? Also in the next version will we be able to group joints multiple times?
-
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?
Advertisement