snapshot as paint input?

Solar2D Advanced Graphics
#1

Is there a way now to use a snapshot or other screen element as a paint input?

Right now it looks like inputs can only be image files, is this correct?

          paint1={ type=“image”, filename=“blob1c.png” },

          paint2={ type=“image”, filename=“blob1n2.png” }

Or perhaps there’s an undocumented…   paint1 = {type = “snapshot”,  snapshot1} or something

along those lines?

***********

In the case I"m thinking of I’d like to explicitly composite snapshotA over snapshotB (subtract, add, whatever), snapshotC over snapshotD, then composite the resulting B and D over whatever happens to be on the screen below it. 

#2

We’ve contemplated something like that. 

The question is where does the snapshot live? Our thinking is that this would go offscreen (i.e. not render) once the snapshot is used as another object’s fill paint.

#3

Walter, regarding snapshots - have you given any more thoughts to my suggestion that they stop being an actual image (of sorts), and instead become a factory resource a la imagesheet, so you can spawn sprites from them? I can’t think of any other conceptual way of having multiple images sharing a single snapshot that doesn’t end up with a system that is alien to corona’s current way of doing things?

I wouldn’t assume that snapshots will just be used for rendering to the screen - at least, not directly. Their greatest strengths are to use them as more than just a filterable container anyway :slight_smile:

What I envisage is that a snapshot works as it does, but you can’t apply it directly to the screen. You’d need to spawn images from it, which gives you the ability to clone them. Something like:

local sprite = display.newImageRect( snapshotAsSource, width, height ).

Or, and this would be even more awesome - make it so you can create image sheets from a snapshot - this would add a TON of useful abilities (for example I am stuck in a demo I am working on because I need to create 10 strips from a single snapshot - currently the only way to do it is to cycle through them 1 at a time per frame).

Creating spritesheets and animations from a snapshot might not seem very intuitive, but being able to spawn sprites based on only sections of a snapshot would greatly increase flexibility, and make the snapshot very useful for setting up graphics to be re-used throughout the project.

#4

Yea, I agree this is going to enable some really amazing stuff!

So what if snapshots could be just as they are today, but also as a source for textures (both images and image sheets).

Here’s what I’m thinking:

-- Create snapshot local snapshot = display.newSnapshot() ... -- Enable snapshot as a source for textures. Move snapshot offscreen. local textureId = graphics.defineTexture( { source=snapshot } ) -- snapshot is source for single image object.fill = { type="image", texture=textureId } -- snapshot is source for image sheet local sheet = graphics.newImageSheet( { texture=textureId } ) object.fill = { type="image", sheet=sheet, frame=1 }
#5

I would love this as well!  We could do dynamic bump mapping and all sorts of fun stuff.

#6

This is very exciting for us! In general I am super excited about gfx 2.0 and we’re hard at work on our new game based on it. 

In the reddit spirit I would just say “shut up and take my money!” :) 

#7

Iffem_shut-up-and-take-my-money-RrJBT46S

#8

Last two posts = most eloquence ever seen in this forum - I am in total agreement. Walter, my only concern is that I’m not fully conversant on the behaviour of fills - as long as an image based upon a snapshot (however it is done, via fill or cloning or something) distorts properly when you do things like distort in 2.75d etc then I’m going to be a happy bunny :slight_smile:

#9

We’ve contemplated something like that. 

The question is where does the snapshot live? Our thinking is that this would go offscreen (i.e. not render) once the snapshot is used as another object’s fill paint.

#10

Walter, regarding snapshots - have you given any more thoughts to my suggestion that they stop being an actual image (of sorts), and instead become a factory resource a la imagesheet, so you can spawn sprites from them? I can’t think of any other conceptual way of having multiple images sharing a single snapshot that doesn’t end up with a system that is alien to corona’s current way of doing things?

I wouldn’t assume that snapshots will just be used for rendering to the screen - at least, not directly. Their greatest strengths are to use them as more than just a filterable container anyway :slight_smile:

What I envisage is that a snapshot works as it does, but you can’t apply it directly to the screen. You’d need to spawn images from it, which gives you the ability to clone them. Something like:

local sprite = display.newImageRect( snapshotAsSource, width, height ).

Or, and this would be even more awesome - make it so you can create image sheets from a snapshot - this would add a TON of useful abilities (for example I am stuck in a demo I am working on because I need to create 10 strips from a single snapshot - currently the only way to do it is to cycle through them 1 at a time per frame).

Creating spritesheets and animations from a snapshot might not seem very intuitive, but being able to spawn sprites based on only sections of a snapshot would greatly increase flexibility, and make the snapshot very useful for setting up graphics to be re-used throughout the project.

#11

Yea, I agree this is going to enable some really amazing stuff!

So what if snapshots could be just as they are today, but also as a source for textures (both images and image sheets).

Here’s what I’m thinking:

-- Create snapshot local snapshot = display.newSnapshot() ... -- Enable snapshot as a source for textures. Move snapshot offscreen. local textureId = graphics.defineTexture( { source=snapshot } ) -- snapshot is source for single image object.fill = { type="image", texture=textureId } -- snapshot is source for image sheet local sheet = graphics.newImageSheet( { texture=textureId } ) object.fill = { type="image", sheet=sheet, frame=1 }
#12

I would love this as well!  We could do dynamic bump mapping and all sorts of fun stuff.

#13

This is very exciting for us! In general I am super excited about gfx 2.0 and we’re hard at work on our new game based on it. 

In the reddit spirit I would just say “shut up and take my money!” :) 

#14

Iffem_shut-up-and-take-my-money-RrJBT46S

#15

Last two posts = most eloquence ever seen in this forum - I am in total agreement. Walter, my only concern is that I’m not fully conversant on the behaviour of fills - as long as an image based upon a snapshot (however it is done, via fill or cloning or something) distorts properly when you do things like distort in 2.75d etc then I’m going to be a happy bunny :slight_smile:

#16

we are converting snapshot images into png files via Flash and using as image files, we have had some successful results with scaling small simple objects. We have not looked into any bump mapping yet. Testing the idea of setting these up in sprite sheets for object textures. We are going to try building the sprite sheets using texture packer.

#17

Hi, I was also trying to know if possible to convert a snapshot into a sprite. There is any update in this subject? a year later? 

Thanks.

#18

Any news on this?

#19

What are you looking for specifically?

Rob

#20

What Walter said above.

I need to be able to create a snap shot and then use that snapshot as a fill or in a composite filter as the 2nd paint channel.

The only way to do that now I believe would be to save and load the image each frame which would kill the framerate.