Alonzo (with and without shadow) should come by default

[ddgarcia]

...that way, we can export using the "long URL" model and not have to text-ify the PNG (which makes it too big).

[jmoenig]

Okay, I can definitely see the benefits of this, but I'm not sure about the implications, that's why I've avoided this so far.

Basically we would always load both (large) PNGs whenever Snap loads. Some folks (like myself) have very low bandwith, so this takes forever (unless it's already cached somewhere), which also applies to mobile devices on even lower bandwith. Another consequence I'm unsure about is whether these would be "special" costumes, which the user can neither edit nor remove from their project (like the default Turtle costume), and which consequently could not be used inside the "next costume" loop. Another thing I don't really like about this version of Alonzo is that it's soo huge. We would need to adjust the default size to - say - 40% instead of 100% just to display it correctly, but then again, this would impact all other costumes the user might import or create for this sprite. I can just anticipate the confusion coming out of this. This really should be an SVG, then textifying it wouldn't hurt at all. So, Snap can already handle SVGs but general browser adoption for rasterizing them on Canvas without tainting it is slow, we'll just have to wait for (especially Chrome) to catch up.

[brianharvey]

On 12/4/13 1:26 AM, Jens Mönig wrote:

Basically we wouldalways loadboth (large) PNGs whenever Snap loads.

No, no. We would load only a small thumbnail. If and when the costume is first selected or edited, that's when we'd load the huge png.

Also, I think it would be an acceptable compromise to use a lower-resolution version. When Dan is making posters he can manually load the huge version.

[ddgarcia]

Right, the hack we'd put in would be that, rather than resizing a big ~1MB file you find the smaller size you like, make a thumbnail, and only load that. Then, when the costume is edited OR GROWN then we load in the higher-res version.

Note that the dimensions are only 397x472, so it's not crazy high number of pixels.

dan

On Wed, Dec 04, 2013 at 07:17:55AM -0800, brianharvey wrote:

On 12/4/13 1:26 AM, Jens Mönig wrote:

Basically we wouldalways loadboth (large) PNGs whenever Snap loads.

No, no. We would load only a small thumbnail. If and when the costume is first selected or edited, that's when we'd load the huge png.

Also, I think it would be an acceptable compromise to use a lower-resolution version. When Dan is making posters he can manually load the huge version.

---

Reply to this email directly or view it on GitHub:

https://github.com/jmoenig/Snap--Build-Your-Own-Blocks/issues/254#issuecomment-29812819

Dan Garcia, Ph.D. 777 Soda Hall, 510.517.4041 ddgarcia@cs.berkeley.edu Senior Lecturer SOE UC Berkeley, EECS dept cs.berkeley.edu/~ddgarcia

[brianharvey]

Actually, Dan, what I'm suggesting is that when the costume is used we load a midsize file, not your current huge file, suitable for just playing the project, not making a high-res poster. If you wanted to do that, you'd manually load the huge version.

[ddgarcia]

I just used "PNG smallest/slow" (still lossless) and got the file size down from 1MB to 250KB. The next question is whether it makes sense to have an image bigger than 360px of vertical space? (I had perhaps mis-remembered that when we went to full-screen mode on a higher-rez screen that it used an internal 720px version if it had one)

I guess I need to know Snap! does when the user drags in a HUGE (in terms of width x height resolution, not file size in KB) file...

dan

On Wed, Dec 04, 2013 at 08:34:01AM -0800, brianharvey wrote:

Actually, Dan, what I'm suggesting is that when the costume is used we load a midsize file, not your current huge file, suitable for just playing the project, not making a high-res poster. If you wanted to do that, you'd manually load the huge version.

---

Reply to this email directly or view it on GitHub:

https://github.com/jmoenig/Snap--Build-Your-Own-Blocks/issues/254#issuecomment-29820766

Dan Garcia, Ph.D. 777 Soda Hall, 510.517.4041 ddgarcia@cs.berkeley.edu Senior Lecturer SOE UC Berkeley, EECS dept cs.berkeley.edu/~ddgarcia

[nathan]

We could do what Scratch 2.0 does: give bitmap images intrinsic scales (like 1/2 or 1/4) and still use the high resolution image. That way they don't look blurry when they are scaled up, but the image is a reasonable width and height when the sprite's size is 100%.

[jmoenig]

Yeah, double bitmaps internally are nice, but they also use up quadruple resources :-) I'd rather use SVGs once they're better usable for canvas graphics.

Incidentally, Snap will currently scale down anything that's bigger than 480 * 360 pixels when the image is imported, but I'm thinking about loosening this...

[nathan]

Yeah, double bitmaps internally are nice, but they also use up quadruple resources :-) I'd rather use SVGs once they're better usable for canvas graphics.

SVGs (especially complex ones like you'd need for the Alonzo above) perform a lot slower than double bitmaps. They do use less memory, but I don't think costume image memory is much of a concern for Morphic.js, considering that it's storing a huge number of canvases, some way bigger than 960x720, already.

Snap will currently scale down anything that's bigger than 480 * 360 pixels when the image is imported

But it doesn't retain the original resolution.

[cycomachead]

Incidentally, Snap will currently scale down anything that's bigger than 480 * 360 pixels when the image is imported, but I'm thinking about loosening this...

@jmoenig Does snap! still do this? Given the larger stage it might be nice to have larger costumes. :)

[marwahaha]

What's the status of this? I think we agreed that both turtle and alonzo will be pre-loaded sprites

[brianharvey]

Yes, but it'll be 2D Alonzo, not 3D Alonzo. (A less pixellated 2D version would be fine if someone wants to work on that.)

Brief recap of discussion: Scratch was intentionally, and correctly I think, designed with a 2D world, because 3D requires the user to pay attention to too many not-really-programming things such as camera angle. Thus even their new vector costumes are 2D. Having one 3D costume raises confusing expectations that the costume's rotation around the Y axis (yaw?) will change when you turn the sprite. (The version with shadow looks particularly stupid when rotated. What, the sun rotated too?)

There is a long, long history of educational software developers getting caught up in the excitement of the latest multimedia capabilities and just throwing them into software, with the unintended consequence of losing sight of the educational effect. We aren't going down that road.

[cycomachead]

Having one 3D costume raises confusing expectations that the costume's rotation around the Y axis (yaw?) will change when you turn the sprite.

(I agree about the shadow, but that's not the point...) Why though? Maybe I've just approached things differently, but I don't see the 3D alanzo as something that's 3D. It's not 3D. It's a 2D image drawn in a perspective.

Not that I completely disagree because 2D alanzo is much cuter and less creepy.

Once we get a good costume previewer in place, I don't see why we shouldn't be able to have all these versions at least available to users.

[brianharvey]

We (the role models, the software/curriculum designers, the teachers) should whole-heartedly embrace the 2D-ness of the Scratch/Snap! world. If we say, in effect, "2D is good enough for cute toy costumes, but our official mascot we want in 3D" we are patronizing the students and making them unhappy with the tools available to them. If a 2D paint editor, for example, is good enough for the students, it's good enough for us, and that's the message we should send. I think it's wrong of Dan to have made that 3D model in the first place, it's wrong of him to use it on posters and things, and it would be extra super wrong for us to put it in the software.

[ddgarcia]

The world is 3D.

2D paint editors allow people to create 2D objects that look like they have depth. Only about 25% of the Scratch icons are fully flat. The rest, while not shaded-3D, convey depth, even Gobo (the original "flat" Alonzo). Their newest professionally- illustrated vector people are simply gorgeous, and all look like Disney "toon-shaded" 3D characters: boy1, boy2, girl1, girl2, etc. (I guarantee these were not created in Scratch's built-in SVG editor)

More than 90% of the Scratch "stage" media have significant depth, so you can place these objects on the stage and give the illusion of 3D on the 2D stage.

Now, if what you're complaining about is the "rendered" look of the 3D Alonzo, then I ask you to look at the Scratch sprites which are photographs of 3D things: Dog Puppy, Dan, Referee, Football -- all more 3D realistic than 3DAlonzo.

It's wrong for us to tell the users what they want -- many will love the 2D world, many will want to create Disney-multi-plane simulations: http://youtu.be/YdHTlUGN1zw and many will want to explore true 3D (scratch has many of these from advanced users, the best of which is an incredibly fast 3D rubiks cube and 3D renderer).

I see your point that we should only include media that could be created with our own tools, but we don't have an audio editor nor is one coming yet we support sounds. Scratch includes many beautiful SVGs that could have been created in their editor but I'm sure weren't. I have no problem with students using other tools outside of ours to create media, so I have no problem including 3DAlonzo.

dan

On Wed, May 07, 2014 at 09:14:53PM -0700, brianharvey wrote:

We (the role models, the software/curriculum designers, the teachers) should whole-heartedly embrace the 2D-ness of the Scratch/Snap! world. If we say, in effect, "2D is good enough for cute toy costumes, but our official mascot we want in 3D" we are patronizing the students and making them unhappy with the tools available to them. If a 2D paint editor, for example, is good enough for the students, it's good enough for us, and that's the message we should send. I think it's wrong of Dan to have made that 3D model in the first place, it's wrong of him to use it on posters and things, and it would be extra super wrong for us to put it in the software.

Dan Garcia, Ph.D. 777 Soda Hall, 510.517.4041 ddgarcia@cs.berkeley.edu Senior Lecturer SOE UC Berkeley, EECS dept cs.berkeley.edu/~ddgarcia

[marwahaha]

How does this sound?

On startup, load two costume thumbnails - turtle (default) and midsized Alonzo. 3D and 2D Alonzo are available from the Media Library.

[brianharvey]

Made by modifying Gobo in the Scratch vector editor then rasterizing in Illustrator. File is 2Kb. I say we use this one, always load it, but not select it by default. (P.S. This one has the wry smile instead of the open mouth, too.)

[nathan]

The stroke width is really thick compared to Scratch. Did you change that or did Illustrator do something?

[brianharvey]

I changed it. Do you not like it?

[nathan]

I like the Scratch one a little better, but that's just my opinion. You might want to make the stroke width on the middle leg match the rest of the outline, though.

[cycomachead]

I think I agree with @nathan.

Also, this is much better than old 2D alonzo. Could I get the original? (Maybe drop it in the BJC dropbox?) I've got a few uses for this. :)

[brianharvey]

Done. Also, the gif is in snapsource/Costumes.

[cycomachead]

I was hoping for a larger version. :)

(But it's not urgent!)

[nathan]

Or the SVG.

[brianharvey]

The reason I didn't put up the SVG is that it isn't usable in Safari. I could add both to the Costumes library, but I think the loaded-by-default one has to be the gif. I don't like it either.

[nathan]

The SVG is useful for other things, though.

[brianharvey]

@nathan For the second day in a row, Berkeley computers are rejecting ssh connections. When that gets fixed I'll post the svg.

[brianharvey]

alonzo.svg is in snapsource/Costumes as well as alonzo.gif. Jens doesn't want to preload anything because (1) it's slow, and (2) some teachers are telling him that it's a plus for their classes not to have the cartoony figures around. So this is officially on hold at least for now.

[brianharvey]

Update: SVGs that come from URLs don't really get loaded into the project, just a reference, and so projects won't work offline, and so we are rasterizing costumes from /Costumes, and so I've moved alonzo.svg to s.b.e toplevel where people can download it and then import it from their disk. :-(