You can also change the text to be a single space. Double click the text, press space and then enter twice.

@wacov said:

It works for me, just not in any events.

Not sure I understand. Can you post a model that fails and I will take a look.

I understand. But it will have to wait for a future version. Microsoft has two different controller api's. One for pc style joystics and one for 360 style. I used the common one because thats what most folks have. I will add the 360 style as soon as I can.

@whaat said:

Hi Chris,

If I have the camera aspect ratio set, and then play a saved SketchyReplay, after the replay is finished, the aspect ratio gets set back to zero (default). This is a problem for exporting the animation to Indigo because the user will set the aspect ratio to the size of the render and SP should not be changing these values. I hope this is a good enough explanation of the problem. Please fix this before SP3 official release.

Thanks!

Noted. Thanks Whaat.

I am not 100% sure that works in this version. It may depend on some unreleased code. Can anyone confirm it works?

You need to use the Face.mesh method to get a PolygonMesh (a triangulated version of the face) and then export that. If you try to work with Sketchup Faces you are going to find that you have to deal with them being potentially non convex and having "holes".

Are you talking about the two analog triggers on top of the controller? If so that is "lt" and "rt". BUT. They dont quite behave as you'd expect. If you hold the left one down you will get a value of -1 and if you hold the right one down you will get a 1 if you hold both down you get a value of 0.

No I wasn't. I had forgotten about that. It helps a quite a bit 68 sec without, 11 sec with, and 6 sec if no start/commit used.

But still first run 11 sec and second run it only takes 2 sec.

After doing some more testing I have narrowed it down a bit further. Part of the problem seems to be in the undo system. Code that runs between operation_start and operation_commit slows down much more than code runs outside.

I have a loop that moves all the verts in a group. With 11k verts a run takes 68 seconds if I use start/commit and about 6 seconds without.

But there is still something else going on. The second run is always at least 2 times faster. Even with start/commit where it takes 68 seconds the second run is 9 seconds.

Argh!

I am experiencing some weird behavior out of Ruby and I wonder if someone has any idea what is going on. Using my SketchyFFD plugin if I weight a large model (11k verts) the first time it takes 17 seconds, the second time 13 seconds and the third 7 seconds. Exact same code exact same model. WTF?

Also an array.each over 11k elements gets slower and slower as the loop gets near the end. The first 1000 take a second but the last 1000 takes about 12 seconds. Again WTF?

I found another way to speed the updates. A model with 11300 verts takes about 90 seconds to update in this version and about 6 seconds with the new method.

But it order to get it ready for release I would almost have to rewrite it. Because it would be a significant amount of work I am thinking I might make the new one a "Pro" version.

Question: How many would be willing to pay for a version with some significant updates? And what would be a fair price to charge?

Thanks Stefan! Its a nice idea. I updated the plugin with an adaption of the code and applied it to the Bernstein Polynomial as well. It sped up the initial weighting of a big model from 75 seconds to 15 seconds.

I also figured out a way (in theory) to speed up the actual deformation by like 50x. The only problem is I would have to handle moving the control points without using any of Sketchups tools like select, move and rotate. Ugh!

It would be possible with the SP3x version. You would have to use the sketchup api to change the material on the group.

Here is a simple example of what I mean.

Washer.skp

Nice model!

Its a Newton limitation. In the case of a wheel you can get around it by making the wheel out of segments. The outer part of each can be as round as you want but the inner segment needs to be straight. Think of a washer with a square hole. Each side of the square in the middle and part of the outer rim is a segment. More segments will mean the inner hole is more round.

Nice code Phy! I love how Ruby makes such a simple concise thing possible.

Its a pretty good model! I am not exactly sure why it fails but here are a few ideas.

Make the inner part of the wheels thicker. The part that goes inside the track may be too narrow.

The wheels seem to be turning very fast. I expect that is to simulate the friction of a big heavy train. But its like the train is burning rubber the whole time it is moving. And when those very fast spinning wheels finally catch on something the whole wheel jumps.

Sketchup underlying unit is "inches" so that is what the dimension values are.

"Force" type values like accel/damp are not any real world unit.

Welcome back BTM! Awsome plugin.