Transformations Extension Suggestion

garnetluvcookie

Alchemyste wrote:
this is a great idea

Please tell why you support, this is a discussion forum, not a ballot box.

garnetluvcookie

Mazmythic wrote:
I support!

Please look at my above reply.

--Explosion--

ampara wrote:
--Explosion-- wrote:
Also these mockups are amazing! Has anyone made any of the actual coding for these blocks yet?

Not yet. We plan to try though!

Cool!

Vubobinali

This idea looks freaking amazing, I totally support it

fdreerf

ContourLines wrote:
fdreerf wrote:
~snip~
Now that's what I call fake news
uh… how? we just want to say that we're in favour of it

Read the stickies

ampara

garnetluvcookie wrote:
First, let me tell you that that was the best post I've ever seen.

I really like this! I hate having to go into my preferred drawing program, drawing what I want, and using a tool to make it like that! Then I have to export it as an SVG, and that is just tedious, and takes up a good half hour of my day, or with this it would only take me 30 seconds to get the extension, and click a block. Mega support!

-garnet

Thank you!

and yes, importing svgs one costume at a time is tedious and frustrating, especially for animations.

ContourLines wrote:
Full support. This would really help with 3d animations and extend the reaches of scratch. Although, this function might be quite hard to program…
lol, how you are making these suggestions, ampara, makes me want to spend hours on my posts too xD

So, I can't be 100% sure of course since we haven't begun trying to build the extension for the ST, but as qucchia said, there are often default functions that control transformations. In fact, every single feature I described in this post was from another software's transformation abilities, so this is widely spread, meaning there are likely many places to reference!

a bunch of people wrote:
Support!

I appreciate the support! As mentioned by others above, please tell us why you support it! Also, if you have any questions, suggestions, or see any problems, please let me know, I am happy to address them.

Last edited by ampara (June 20, 2020 14:02:23)

DarthVader4Life

You are a smart person. This would make animating a lot easier. And possibly make a new way of animating on scratch. (idk that last part.) anyway, I see 0% reasons to not support, well, actually 5% reason to not support; You are able to do the same stuff (manually) in the paint editor, so some might see this unnecessary. You has a support from me tho.

Last edited by DarthVader4Life (June 20, 2020 14:14:12)

mrCamelCase

Full support! Nice OP.

ampara

DarthVader4Life wrote:
… I see 0% reasons to not support, well, actually 5% reason to not support; You are able to do the same stuff (manually) in the paint editor, so some might see this unnecessary. …

Thank you, and that is a valid point! However, I think this would extend beyond the capabilities of just making a bunch of costumes, as maybe a user input would impact the transformations in a certain way, and you can't easily predict the many user actions that are possible. Thank you for your input, it is highly appreciated!

Last edited by ampara (June 20, 2020 14:28:09)

Nambaseking01

Fantastic post you made there! How I wish I could do Vector Art that well…

Anyways, that's an amazing idea! I think of so many game ideas in which that could be useful - it's a lot better than the size manipulation.

Maximouse

Good idea. What about matrix transformation? That would be useful too and have even more options.

ampara

Maximouse wrote:
Good idea. What about matrix transformation? That would be useful too and have even more options.

That's true! That would be too complicated for the average user though, in my opinion at least. I feel that (with rewording) this extension idea is fairly straightforward for most users at the moment, but making it any more complicated might be a little too confusing for some.

ampara

Oh - I also wanted to clarify something! Using the

[vertically v] shift [right v] by ()  ::#0fbd8c

block in a direction perpendicular to the side being transformed.

[horizontally v] shift [right v] by ()  ::#0fbd8c

Basically, it would be functionally similar to scaling the object horizontally, however the left side's position would stay unchanged. Meaning, it is basically scaling the object to a specified width in the rightward direction:

Jedibrine

100% support, I've found myself needing this MANY TIMES for graphic effects and it can be used to make physics more realistic.

mlcreater

This would make so much easier perspective drawings, 3-dimensionality simulations, general pen (stamping) polygons, and other things mentioned at the bottom of the original post!

I have some thoughts about some details:

When drawing a sprite which is transformed and rotated, which should be done first?
I think the transforms should come first, and then the rotation last.
Should not there be a
```
clear transformations :: extension
```
block?
I saw the part suggesting the block
```
[vertical v] transformation :: extension reporter
```
; what does this mean exactly?
I think there should also be a block:
```
flipped? :: extension boolean
```
returning if the sprite's transformations flip it overall; if or if not it is a mirror image.
To determine this, Scratch should evaluate the expression:
```
<((([left v] scale :: extension) + ([right v] scale :: extension)) * (([top v] scale :: extension) + ([bottom v] scale :: extension))) < (0)>
```
I also think there should be a block:
```
shift of [top v] to the [left v] :: extension reporter
```
, just to help programs remember how far they have shifted sides of sprites.

ampara

mlcreater wrote:
This would make so much easier perspective drawings, 3-dimensionality simulations, general pen (stamping) polygons, and other things mentioned at the bottom of the original post!

I have some thoughts about some details:
When drawing a sprite which is transformed and rotated, which should be done first?
I think the transforms should come first, and then the rotation last.
Should not there be a
clear transformations :: extension
block?
I saw the part suggesting the block
[vertical v] transformation :: extension reporter
; what does this mean exactly?
I think there should also be a block:
flipped? :: extension boolean
returning if the sprite's transformations flip it overall; if or if not it is a mirror image.
To determine this, Scratch should evaluate the expression:
<((([left v] scale :: extension) + ([right v] scale :: extension)) * (([top v] scale :: extension) + ([bottom v] scale :: extension))) < (0)>
I also think there should be a block:
shift of [top v] to the [left v] :: extension reporter
, just to help programs remember how far they have shifted sides of sprites.

1. It would be the order that the blocks are placed. i.e. if you put the “point in direction ()” block first, it'll rotate first. If you put scaling first, it will scale first.

2. Yes, and I meant to include it. I used an older version of the block library in the first part. I'll try to get that fixed.

3. I don't know how that got in there, haha. I really should've looked back at that first part, I made it the day before.

4. there is already a block in the library for that function:

<flipped [vertically v] ? ::#0fbd8c>

5. I agree. When I get the time to make all of these changes that I've mentioned above, I'll add that one.

Really great comments, I appreciate it!

Last edited by ampara (June 20, 2020 19:24:20)

mlcreater

ampara wrote:
mlcreater wrote:
I think there should also be a block:
flipped? :: extension boolean
returning if the sprite's transformations flip it overall; if or if not it is a mirror image.
To determine this, Scratch should evaluate the expression:
<((([left v] scale :: extension) + ([right v] scale :: extension)) * (([top v] scale :: extension) + ([bottom v] scale :: extension))) < (0)>
4. there is already a block in the library for that function:
flipped [vertically v] ? :: extension boolean

Okay, then one of the options in that block should just be

flipped [overall v] ? :: extension boolean

or similar.

ampara

mlcreater wrote:
ampara wrote:
mlcreater wrote:
I think there should also be a block:
flipped? :: extension boolean
returning if the sprite's transformations flip it overall; if or if not it is a mirror image.
To determine this, Scratch should evaluate the expression:
<((([left v] scale :: extension) + ([right v] scale :: extension)) * (([top v] scale :: extension) + ([bottom v] scale :: extension))) < (0)>
4. there is already a block in the library for that function:
flipped [vertically v] ? :: extension boolean
Okay, then one of the options in that block should just be
flipped [overall v] ? :: extension boolean
or similar.

That might be somewhat confusing. It might make more sense / be more intuitive to use:

<<flipped [vertically v] ::#0fbd8c> or <flipped [horizontally v] ::#0fbd8c>>

Last edited by ampara (June 20, 2020 19:24:02)

mlcreater

ampara wrote:
mlcreater wrote:
ampara wrote:
mlcreater wrote:
I think there should also be a block:
flipped? :: extension boolean
returning if the sprite's transformations flip it overall; if or if not it is a mirror image.
To determine this, Scratch should evaluate the expression:
<((([left v] scale :: extension) + ([right v] scale :: extension)) * (([top v] scale :: extension) + ([bottom v] scale :: extension))) < (0)>
4. there is already a block in the library for that function:
flipped [vertically v] ? :: extension boolean
Okay, then one of the options in that block should just be
flipped [overall v] ? :: extension boolean
or similar.
That might be somewhat confusing. It might make more sense / be more intuitive to use:
<<flipped [vertically v] ::#0fbd8c> or <flipped [horizontally v] ::#0fbd8c>>

It would have to be eXclusive OR because if a sprite is flipped both ways then it is no longer a mirror image…

I guess anyone who wants to can make a custom block, so the <flipped ?> thing doesn't need to be added in the extension.

--Explosion--

Bump! Not my topic but a great suggestion!

Discuss Scratch