Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

[RELEASED] PixelSurface: Efficient Destructible 2D Terrain

Discussion in 'Assets and Asset Store' started by JoeStrout, Nov 13, 2015.

  1. MD_Reptile

    MD_Reptile

    Joined:
    Jan 19, 2012
    Posts:
    2,664
    You got me thinking, I tried A* doing multithreading, and although it alleviates lag on the main thread, it just plain takes too long. So what about this - similar to your caves generator, and how it generates grass at the top area of terrain, you could do a similar method to label all "walkable" pixels, rather than using an a* grid (which considers all kinds of places you can't possibly reach in a sidescroller) and instead just check heights along "walkable" lines, and if they are not too high to jump too, they are valid paths across, and then it's a matter of connecting the paths, and anywhere that is an obstacle, destroy it, and wherever there is a gap, bridge it somehow (for my game I might try having the ai use the "pixel sprayer" to create a little bridge). It would mean way less nodes for pathfinding to consider, and need basically a simple heuristic based on y height of the separated walkable areas...

    Is this making sense to anybody? :p

    Edit:
    Like this -
     
    Last edited: Apr 12, 2016
  2. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    Yeah, sounds good.

    But pathfinding in a platformer is tricky even in a tile-based world... with a pixel world, it's going to be even harder. Super Mario Bros didn't have any pathfinding at all; enemies just used very simple behaviors (e.g. walk until you reach a cliff or an obstacle, then turn around). All the fancy movements are left to the player.

    I don't know what game design you're working on, but is it possible to alter it in such a way that you can dispense with the smart AI completely, and still have a fun game?

    Just thought I'd ask! :D
     
  3. MD_Reptile

    MD_Reptile

    Joined:
    Jan 19, 2012
    Posts:
    2,664
    I'm working on a shooter, with weapons like an rpg, rifles, and tools like a digging tool and pixel spraying tool, and the idea would be either A) decent ai who can find players who have dug deep into the level (like zig zagging through 8192 pixels) even when they have to travel through obstacles and bumps too large to jump by modifying the environment. Or B) online multiplayer. Forget ai altogether and focus on making it a deathmatch/ctf/attrition style gamemode, based on kills or objectives, with the ability to blow away parts of the enemy base, create obstacles to prevent enemies reaching your own base... I could go on, but I guess the thing is, I halfway hope to let unet mature before I mess around with networking, as I don't want to screw it up having problems that are possible bugs in unet, plus it's hard to network this, so I've kind of focused on a single player aspect instead, with the hopes of having the ai compare to the likes of Cortex Command (google a gameplay video or better yet grab a copy on steam - I can't believe you've made this asset and haven't heard of CC :p ).

    I will keep brainstorming for ideas that might work for my AI - but they used a type of A* in CC, which has a smaller resolution grid of nodes, and does some "magic" to determine paths the ai can reach - and they can reach anywhere... Definitely check it out if you haven't already!

    Edit: I might tear into this code and see what they do -

    http://www.openlierox.net/
     
    Last edited: Apr 7, 2016
    JoeStrout likes this.
  4. frekiidoochmanz

    frekiidoochmanz

    Joined:
    Feb 7, 2016
    Posts:
    158
    interesting, will have to astudy this. it should be possible since the pixels leave a changed squad zone after falling right?
     
  5. MD_Reptile

    MD_Reptile

    Joined:
    Jan 19, 2012
    Posts:
    2,664
    Hrmm straight c++ isn't my strong point, but I have started figuring out a bit about how these guys handle ai just from observation. Their AI and players can use grappling hooks, and seems to use a A* as far as I can tell, one which doesn't need to consider gravity or anything else because with grappling hooks they can go anywhere basically. Anyway I might try digging in a bit more and see if anything of use is hidden in there haha.

    I could be mistaken, and they might be obstacle avoiding dumb ai, who just go towards a player or enemy direction and avoid collisions along the way.
     
    JoeStrout likes this.
  6. mgear

    mgear

    Joined:
    Aug 3, 2010
    Posts:
    9,350
  7. MD_Reptile

    MD_Reptile

    Joined:
    Jan 19, 2012
    Posts:
    2,664
    (Combined posts)

    Yep mgear I have been seeing that one while googling around, and if I have a breakthrough on the a* speed side of things, I'd definitely try implementing something like that page describes.

    (Second post)

    Ok, been doing more A* testing... finally getting better results after a bit of work:



    As you can see in that pic, I am getting over 1000 "pixel" long paths (meaning closer to 1000 * 8 total nodes checked) in under a second and a half!

    Not bad at all! Strangely enough, it seems how I have it set up, it loses that speed at bigger sizes. A 4000 pixel long path took more like 25 seconds, while a 8000 pixel long path took over 2 and half minutes.

    So yeah, still plenty of kinks to work out, obviously something ain't right since those ratio's don't match up, but at least the shorter pathfinding is working well!

    PS hope you don't mind me going semi-off topic all the time in your thread Joe :p

    I'll keep cracking away at this problem.
     
    Last edited: Apr 12, 2016
    JoeStrout likes this.
  8. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    I don't mind. I have one suggestion: during development & debugging, have your pathfinding algorithm call SetPixel on each pixel it expands as it goes. This may provide some insight into what it's doing on longer paths, and will certainly make some pretty pictures. :)

    (As it happens, years ago I wrote an article on path-finding in REALbasic, which had a visualization like that. It was really interesting to look at different variations on the algorithm — depth-first aka greedy, breadth-first, and best-first aka A*.)
     
    MD_Reptile likes this.
  9. MD_Reptile

    MD_Reptile

    Joined:
    Jan 19, 2012
    Posts:
    2,664
    (combined previous post)
    I actually just implemented something like that yesterday, but just for the actual path, rather than say, all visited nodes in the search, but I was tinkering with that kind of idea.

    I'll have to rewrite it to color code and create a visual of the whole process, and that way it should look pretty nifty, and actually help me figure how well it's working better!

    Hrmm, REALbasic huh, a variant of BASIC I'll assume? Perhaps I can cheat sheet that a little then.... been years since I mucked about in BASIC though...

    Prepare for incoming pictures of the resulting silly mess within the coming few days, or sooner if the coding gods permit.

    (new post below)

    Sneak preview :p - In this shot, its just a line for the path itself, from player up to the top right corner of the world (no considerations for gravity or jumping, just raw A*)

    picpic.png
     
    Last edited: Apr 12, 2016
    JoeStrout likes this.
  10. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    Neat! Though if this case is typical, it's just screaming for a depth-first (i.e. greedy) search rather than A*...
     
  11. MD_Reptile

    MD_Reptile

    Joined:
    Jan 19, 2012
    Posts:
    2,664
    I am not totally sure what the use cases will be yet, but more than likely it'll be used for AI to find their way to the player, or to goals, to protect from the player.

    There are plenty issues still, and once I have ironed a few more of those out, I'll bring a more interesting screen or gif, and potentially a more sensible use-case haha.

    EDIT:

    Okay, got some cool GIF captures to show off :p

    Now bear in mind, to actually do the drawing for every single pixel the A* tests against, really slows it way down...

    Anyway, follow these gyazo links to see, and notice the closed set is magenta, the open set is cyan. I created a little chunk of overhang to "trap" the pathfinding there.

    https://gyazo.com/87f5453856e58747c2e03060301265ee
    https://gyazo.com/cde0bfaeeb95917aa91c48e48d27439f

    Is this the way A* should really search? In this gif you see it started the search from the bottom left of the map, looped through and basically flood filled the entire lower tunnels, before eventually breaking out to find a more acceptable path quickly for the upper tunnels...

    https://gyazo.com/e07d2e5628129185825d5edb22776925

    It might just be the way it is supposed to work and that is an awkward spot for the algorithm to find it's way... or I might not be properly handling the heuristic or something.... *scratches head*

    And here is a pic of a short path in yellow, the closed set in purple, and open set in blue -


    EDIT2 (4/13/16):
    I tried another implementation, very similar to mine, but written in a way I thought it would be faster ( http://blog.two-cats.com/2014/06/a-star-example/ ) and it was fairly easy to get it working, but I found that since it keeps 2d arrays of every node in the level, rather than my approach which only creates nodes as it first encounters them, that there was a lot more overhead from just having it running. And since every agent would need his own "version" of the nodes relative to his own position, I imagine this approach would ultimately become slower than just creating nodes that the agent will actually be near on the way to a specific goal.

    Pathfinding is tricky stuff!
     
    Last edited: Apr 14, 2016
    JoeStrout likes this.
  12. frekiidoochmanz

    frekiidoochmanz

    Joined:
    Feb 7, 2016
    Posts:
    158
    Couldn't you make a singleton node class which updates the definable "non-obstructed areas" to each node every deformable event it would update (called in changed actions, such as destroyPixel) and then each gameobject for AI reads the map from this one class and wont actually know anything that it doesnt know. So everyone on the map doesnt need its own version of nodes relative to anything, just the nodes period. The logic would need to be calculated one time and read and take a from and to position. I think A* pro does something similar.
     
  13. MD_Reptile

    MD_Reptile

    Joined:
    Jan 19, 2012
    Posts:
    2,664
    It is a bit too much memory overhead to keep "nodes' representing the entire graph (if that is what you mean), plus each node would need its own heuristic calculated and stored for each AI agent anyway, and the distance to goal comparison would need calculated per-agent as well depending on their goal node.

    My worlds get as large as 8192x4096 as of right now, and I intend to test even larger worlds! That would mean 35.5 MILLION "nodes" if I represent each pixel as a node... So... I have steered away from keeping an entire graph of nodes, and instead have tried generating nodes as they are discovered, and keeping the ones that have been found as a growing "pool" of nodes, so that if nodes get checked more than once, they don't have to be re-created, just values changed.
     
  14. frekiidoochmanz

    frekiidoochmanz

    Joined:
    Feb 7, 2016
    Posts:
    158
    oh interesting, well I didnt know, hmmm...
     
  15. MD_Reptile

    MD_Reptile

    Joined:
    Jan 19, 2012
    Posts:
    2,664
    I found a faster way to do pathfinding, albeit less dynamic...

    I decided that since the AI is stuck on (or near) the ground because of gravity, I don't need to know any pixels but the open ones right above the ground...

    If I make a path from point A to point B - I can do a linecast down from those points, and make those start and end nodes. Then I check in the X direction towards the goal, and if it is a "walkable" (not too high, too low) neighbor, then add it to a list for the path. I then keep finding walkable neighbors towards the goal until you can't get any closer (at which time, have the AI either start improvising by blowing holes in something, or jumping over something, or build pixel bridge...) and call that a path.

    Obviously I'll need to slow it down some by also checking if there is enough head room for the character to fit through gaps... but for now I am pleased with the speed improvement!

    This basically means checking wayyyy less nodes. Way wayyyy less. In turn it is at least like... 20 times faster haha. I am still experimenting and I'll post more info about that on my own thread for Pixel Destruction. For now here is another pic of the resulting "path" line:

     
  16. frekiidoochmanz

    frekiidoochmanz

    Joined:
    Feb 7, 2016
    Posts:
    158
    I got a question, im trying to figure this out, each image we want to have destructable, must have its own PixelSurface.cs component and write-enabled on its image? like I want a building to collapse and then become destructable in the terrain, but only when it stands still. or msybe i want a ton of rocks falling and then becoming destructable static pieces? each object gets its own pixelsurface.cs?
     
  17. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    No. All of those would be in the same PixelSurface. You only need more than one if you want to have different layers, each with its own pixels (both static and dynamic) for some reason. For example, in the demo, we use an extra PixelSurface for the drawing tools. This is where we draw the rectangle or oval or whatever while you're dragging the mouse, so we can easily clear it and draw a new one whenever the mouse moves. Then when the mouse is released, we draw into the "main" PixelSurface.

    (Note: I'm traveling this weekend, so may be slow to respond... but I'll get caught up ASAP. Thanks for your patience.)
     
  18. frekiidoochmanz

    frekiidoochmanz

    Joined:
    Feb 7, 2016
    Posts:
    158
    ah I got it now, thank you. So the Surface is where the "destruction work" takes place, per PixelSurface layer ( I'll take a look at the docs again, was a bit confusing the first couple of times) and I'm sure we can change each layer for each image we want in the layers.) Pretty cool. I'll experiment with it some more. Thanks again.
     
  19. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    Sounds good, please let me know how it goes. Also, any place the docs are unclear, please let me know about that too. I want to make them as clear & simple as possible!
     
  20. xgeraldx

    xgeraldx

    Joined:
    Oct 31, 2012
    Posts:
    10
    This looks great....will this work with the current Unity 5.5 or will there be any updates soon? I like what I have seen in the forum so far, really interested in the destructible aspect, like good ole Scorched Earth.
     
    JoeStrout likes this.
  21. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    It works fine as far as I can tell, and the only reason for the lack of updates is that (1) nobody has asked for any, and (2) they're a bit of a pain in the neck to do. ;)

    But you raise a good point; I'll test it thoroughly and try to submit an update this week, so people can be confident about it working in the latest version.

    If it helps, I'm using it in an iOS game that is so close to being finished — I just need to wrap up in-app purchases, and it's ready to go! It's a full-screen continuous scroller with a lot of dynamic pixels, and it's been working great for me.

    There is one other thing that sometimes bugs me about it... when you create tiles in the editor, they can stick around even after you've changed the size or tile settings. I've sometimes had to go in and manually delete them in order to get my PixelSurface fully reset. Not a huge deal, but it could be confusing to new users. So, I'll also see if I can streamline that process somehow.
     
    theANMATOR2b and MD_Reptile like this.
  22. xgeraldx

    xgeraldx

    Joined:
    Oct 31, 2012
    Posts:
    10
    Ok sounds good, I just bought it, thanks!
     
    JoeStrout likes this.
  23. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    No, thank you! :D If you have any trouble with it, just let me know!
     
  24. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    OK, this has turned into a fairly major change. Instead of stopping the tiles from being created in the editor (which was caused by Unity automatically calling my Reset method), I decided to embrace it. So now, whenever you change any of the PixelSurface properties, it instantly updates the tiles, both in the editor and at runtime. And the reset method is a little more aggressive about clearing out old tiles (deleting any immediate child whose name starts with "Tile " and which contains a mesh renderer).

    I think the resulting behavior is really handy — it makes it very easy to see what you're doing, right in the editor! But I'd love to get some testing and feedback from y'all before I submit the update to the Asset Store. (It also contains a couple of other minor goodies.)

    So: anybody who's an existing PixelSurface user and wants to try out the new code, please PM me your email address and I'll send you the updated file!

    Thanks,
    - Joe
     
  25. MD_Reptile

    MD_Reptile

    Joined:
    Jan 19, 2012
    Posts:
    2,664
    I'd totally check it out if I wasn't going full tilt on things with my own project - I may be trying out a implementation of your eulerian water sim on the GPU soon!
     
    JoeStrout likes this.
  26. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    Hey everybody, in the spirit of "eating my own dog food," the boys and I made a PixelSurface-based game for iOS that's just been released!

    It's called Rocket Plume, and it looks like this:



    It's an infinite cave flyer, so we use two PixelSurfaces, stacked one above the other. As soon as one goes off the screen on bottom, we reposition it up top, and generate new obstacles (these are procedurally generated with a seed based on the current date, so you get a different cave each day).

    All those particles spewing out of the business end of the rocket are LivePixels, and when they hit rock, they both bounce and also destroy a bit of the rock they hit. So, by pointing your exhaust plume at what you want to destroy, you can quickly chew right threw it... while accelerating in the opposite direction. This tension between making a gap where you want to go, while having to accelerate the opposite way, is what I think makes it so much fun to fly.

    Performance on all our test machines is excellent, even with all those live pixels.



    Anyway, just thought I'd share, as an example of what can be done! And now that that's off my plate, I'll see about pushing out that new version of PixelSurface to the Asset Store...
     
    Last edited: Apr 11, 2017
  27. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    Hey gang, I finally got PixelSurface version 1.1 submitted to the Asset Store! It includes these cool enhancements:
    • Added work-around for a Unity bug in which CreatePrimitive could fail in built apps.
    • Added the GetTileTexture method.
    • Added the IterateOverLine method, for easily finding all the pixel positions along a line between two points.
    • Added a bit of bullet-proofing to an internal update method for cases where a live pixel was removed.
    • Updated PixelSurface to create and maintain its tiles in the editor, updating these as its properties are changed. This makes it much easier to arrange a PixelSurface in your scene.
    • Reset is now called automatically during Update, if any relevant properties have been changed (e.g. tile size or total size).
    I'll let you know as soon as it's published; this is a recommended update for all users.

    While we wait, I don't have any handy kitten videos, but I do have this video of LivePixels flying around by the bajillions... :)
     
  28. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    PixelSurface 1.1 is now out on the Asset Store!

    It has all the goodies listed above. Again, I recommend all users update to this new version — it shouldn't break anything, and in addition to the new functions and nifty in-editor updating, it includes a bug fix or two that you will want to have.

    Have fun, and let us know what you're doing with it!
    - Joe
     
  29. Mcg

    Mcg

    Joined:
    Mar 28, 2012
    Posts:
    112
    this looks interesting just have a few questions

    can you import sprite pixels from an image or can you only manually create your own?
    how does it work with colliders say for example a platformer game?

    thanks
     
  30. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    I'm not sure what you mean by that. If you mean things like the background in the demo scene, or the rocks in Rocket Plume, you can do it either way: copy in an imported texture, or draw stuff procedurally.

    It doesn't interact with the physics engine, but it's easy enough to check pixels yourself and decide what you're colliding with. In the demo, that's how the bomb sprite knows when to explode — it just looks at the pixels under it, and when that's no longer clear, it goes kaboom.

    So for a platformer, you'd do the same thing: just check a couple of pixels under your character's feet. If they're clear; fall; if not clear, stop falling.
     
  31. Mcg

    Mcg

    Joined:
    Mar 28, 2012
    Posts:
    112

    Thank you for the reply :) , yes sorry I should have been more clear but I meant importing a texture/sprite :p

    I look forward to playing around with it !
     
    JoeStrout likes this.
  32. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    I was idly thinking this morning that PixelSurface would be a great way to make a Rampage clone.



    I'd use sprites for the monsters, soldiers, helicopters, etc., and then use PixelSurfaces for the buildings. Probably a separate one for each building in this case, since that lets you layer them however you want. The holes in the building would be cleared areas, revealing food or hazards hidden behind. And when a building collapses, you could move its whole PixelSurface down, clearing the bottom as you go (and hiding the edge with the dust cloud sprite).

    This would be a lot of fun as a multiplayer network game.

    But then I just found out that they're apparently making a Rampage movie, due to come out next year. Surely they'll want a video game tie-in, for marketing if nothing else... hopefully they'll find this thread when the go looking for somebody to create that. :D
     
  33. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    Hey all, PixelSurface is now on sale for 20% off in the Asset Store!

    If you've been on the fence, you can now pick it up for only $16 instead of $20... a great time to jump in and add high-performance pixel operations to your Unity toolkit.

    And remember, if you do any cool projects with it (or even half-baked experiments), don't be shy about posting them here! I'd love to see what you're up to.

    Cheers,
    - Joe
     
  34. wtadlock

    wtadlock

    Joined:
    Aug 1, 2016
    Posts:
    15
    Hey Joe,

    This seems like a great asset. I just purchased it today and trying to figure it out. So, I have a couple of questions for you. I have read through the manual, but being relatively new to Unity, it's a bit of a challenge fore me.

    1. Do you have a start to finish video tutorial. Looking at the demo scene and the code, I can kind of figure it out.

    2. Is there a way to take something created in Ferr2d and use it with PixelSurface since Ferr2d creates meshes, not sprites?

    I will play around with it in the mean time to see what I can do with it.

    Thanks,

    Walter
     
    JoeStrout likes this.
  35. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    1. I don't have a video tutorial. I do however have a detailed (and I hope very clear) manual. If you've only looked at the code, then it sounds like perhaps you have overlooked this — please give it a read-through!

    2. I've never heard of Ferr2d, so I'm not sure, but PixelSurface doesn't care about meshes or sprites. A PixelSurface is (like everything else in Unity) just a GameObject in your scene, in this case, one that can efficiently manipulate and display pixels. You can layer that (in 2D or 3D) with other GameObjects — whether those are sprites, 3D objects, or whatever. So I would expect it to work just fine.

    Good luck, and please let us know how it goes!
     
  36. wtadlock

    wtadlock

    Joined:
    Aug 1, 2016
    Posts:
    15
    Hey Joe,

    Thanks for the response. I did read through the manual, but being an extreme noob to this, I didn't quite understand it. But, I am a pretty quick learner :) However, a quick video tutorial would be awesome for folks like me that are just trying to figure it out. I would recommend checking out Ferr2d, it can be found here. https://www.assetstore.unity3d.com/en/#!/content/11653. I think it would be a good asset along with yours, hence why I have them both.

    Thanks,

    Walter
     
  37. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    OK, I see your point. I'm still not entirely sure what I would show in such a tutorial... the set-up steps are just (1) create a GameObject, (2) add the PixelSurface component, and (3) configure its properties as you like. Everything after that is coding; it's not a edit-in-the-editor sort of asset. But I could still show those steps.

    And thanks for the link to Ferr2d — it does indeed look very cool. It'd be great if there were some way to take a Ferr2d terrain and "bake" (draw) it into a PixelSurface. I have no idea whether/how they would provide such a facility, though.

    You are quite likely the first person to use both assets, so once you get up to speed in both of them, maybe you should start a thread and mention (@JoeStrout, and @-whoever-wrote-Ferr2d) us to get a conversation started about using them together!
     
  38. wtadlock

    wtadlock

    Joined:
    Aug 1, 2016
    Posts:
    15
    I think if you show the coding portion of it, and explain how you set up your demo scene, would be helpful. I was not aware that I needed to write my won script regarding the texture to use on the drawing surface until I tore your demo scene apart.

    And I will take you up on that starting another thread regarding these two assets once I am a lot more comfortable with them. Since Ferr2d creates a Mesh, I have started looking into how to convert ("bake") a mesh object into a texture or material. Maybe creating a camera that only renders the object and creates a snapshot of it. Maybe I'm reaching, but not sure. That is something for a later date.

    Thanks,

    Walter
     
  39. MD_Reptile

    MD_Reptile

    Joined:
    Jan 19, 2012
    Posts:
    2,664
    @wtadlock

    In the component "PixSurfDemo" you see attached to the gameobject "DemoSurface" in the demo scene, is what allows you to select your own texture as the level, like so:

     
  40. wtadlock

    wtadlock

    Joined:
    Aug 1, 2016
    Posts:
    15
    Hey MD_Reptile,

    Thanks for that info :) That is part of what I had figured out when tearing apart the demo scene. If I drop my own texture into it, it works. I am still tearing into it and trying to figure things out. I am currently working on creating the "levels" in photoshop so I can import them in.

    My ultimate goal is to use the random generation script (modified) Joe provided on the first page and see if I an tweak it for my needs for the game I am prototyping. I have been looking all over hells half acre trying to find a proceduralish 2d terrain generator that can be destructible. Ferr2d works well for the generation, just trying to figure out if it can be seeded and done at runtime and possibly exported into a format that PixelSurface can use, but doesn't do destruction, and PixelSurface does destruction like I am looking for based on the demo scene....I have a pretty long road ahead of me I think :)

    Walter
     
    JoeStrout likes this.
  41. MD_Reptile

    MD_Reptile

    Joined:
    Jan 19, 2012
    Posts:
    2,664
    Does Ferr2D let you do a PNG or image format export? If so, could just use that... I'm not familiar with it so can't really add anything else :D
     
  42. wtadlock

    wtadlock

    Joined:
    Aug 1, 2016
    Posts:
    15
    I am not sure if it does or not. I just recently got it and learning it as well :)
     
  43. wtadlock

    wtadlock

    Joined:
    Aug 1, 2016
    Posts:
    15
    @MD_Reptile @JoeStrout

    Reference:
    http://answers.unity3d.com/questions/22954/how-to-save-a-picture-take-screenshot-from-a-camer.html - Answer by Todd Moore

    https://unity3d.com/learn/tutorials/topics/graphics/cameras - @ about the 2 minute mark.

    Gentleman (Ladies?),

    I have figured out a way to do it after a little research, It's not point and click, a little bit involved, and it technically can be used with any asset like Ferr2d that creates objects that can't just be dropped into PixelSurface. Below is what I did.

    1. Created a generic landscape with Ferr2d
    2. Created a new layer (called my screenshots)
    3. Added Ferr2d Landscape to screenshots layer
    4. Set camera culling mask to the screenshot layer (so that is all that it will render)
    5. Set camera clear flags to a solid color and used default blue
    6. Created a screenshots folder 1 level up from the Assets folder (Per the script comments)
    7. Attached the script to the camera
    8. Set the screenshots folder to the one I created on step 6
    9. Adjusted the camera in Orthographic view to get the whole terrain (this part is completely up to the user) and was done for testing purposes only since the script can do continuous screen captures for larger scenes, requires some stitching together in your Gimp, Krita, Photoshop, or whatever.
    10. Opened the created file in the screenshots folder in Photoshop
    11. Removed the background color so that the background was transparent
    12. Adjusted the image size to fit around my terrain
    13. Saved as a new PNG file with transparency.

    I have no idea how many people will find this useful or otherwise, but here it is. If you want to created a realistic platformer with destructible terrain, you can use a terrain editor of your choice, set it how you want it, adjust camera, and there you go.

    Walter
     
  44. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    That's awesome — you keep claiming to be a newbie, but you're doing quite advanced stuff. :)

    In principle you could take this technique a bit further, and take the rendering from the special camera directly into SpriteSurface at runtime. But the advantage of going through PhotoShop is that you have a chance to do further tweaking, and of course your Ferr2d scene or project can be completely separate from your PixelSurface scene or project.

    Anyway, I'm glad you got it figured out — great work!
     
  45. wtadlock

    wtadlock

    Joined:
    Aug 1, 2016
    Posts:
    15
    Thanks sir, I appreciate the compliment. While I am newbie to programming and Unity, I have been in IT for 25 years, so I am able to pick up on stuff relatively quick.

    If I was to go directly from my script to PixelSurface, does PixelSurface have a way to make a certain color transparent? That is the main reason I am going to Photoshop, so I can remove the BG color.

    Thanks,

    Walter
     
  46. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    PixelSurface uses the alpha channel to control transparency. If you set things up right, I'm pretty sure you can take a screen shot that already has proper transparency. (You would set the camera to clear to Color.clear, i.e., a color with an alpha of zero.) But if you can't get that to work, then you could instead just draw your screen shot to the PixelSurface, then loop through all pixels, and change those of your background color to Color.clear one by one.
     
  47. qqqbbb

    qqqbbb

    Joined:
    Jan 13, 2016
    Posts:
    113
    WebGL demo does not open in chrome.
     
  48. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    I don't have Chrome, but if it doesn't load at all, I imagine this is an issue with WebGL on Chrome, rather than with PixelSurface in particular.
     
  49. Nyrt

    Nyrt

    Joined:
    Aug 11, 2017
    Posts:
    1
    Hi! Been rolling some ideas around in my head and happened upon this. I'm a huge fan of roguelikes and have been trying to find an element to spice up something I've been working on and this really sparked a sense of nostalgia for early Worms, Lira extreme, that game with the tanks, and the like. I think I'd really like to make a classic dungeon-crawly roguelike where you (and the enemies) can completely blast up the dungeon. Knock enemies through walls (or get knocked through walls yourself), sneak attack through a wall with explosives, or turn enemies into dust. I am absolutely in love with the mental image of fleeing from a boss that just chews its way through everything in its path to get to you.
    A few questions though before I invest: have you worked put a system for multi-pixel clumps? How would one go about atomizing an enemy sprite? Do you have any thoughts on the feasibility of dynamic 2d lighting occluded by pixel surfaces? Would it be feasible to model the internal pressure/forces on each pixel and destroy them or make them collapse accordingly? (a bit of a pipe dream of mine- I love the idea of procedurally collapsing a room if the support pillars are knocked out. A dungeon buried in sand could be a fun asthetic, now that I think of it.)
     
  50. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    Great ideas! As a fan of roguelikes myself, I would definitely play that game. :)

    OK, to your questions:
    There's nothing really built in for that, but I can think of a couple ways to tackle it. For larger clumps, you might be able to use a sprite. Or (probably better), for clumps of any size really, you could make your own class that keeps track of a set of LivePixels. Then when you move this object, you just move all the LivePixels accordingly.

    Just draw the sprite into the PixelSurface (there is a method for drawing a Texture2D which should work here). Then you can leave it as static pixels, or zip over the sprite area and convert them to some LivePixel subclass to make it explode, burn, evaporate, beam out, or whatever.

    This sounds hard to me, but would probably be doable depending on the resolution of your display (lower resolution is better in this case). I guess you'd use techniques similar to this.

    Sure! This is not exactly trivial either, but it's definitely doable — similar in principle to the fluid simulations discussed earlier in this thread. PixelSurface is really good for making displaying any kind of 2D cellular automaton, so as long as you can come up with the rules for how it should work, you should be able to implement it this way. See The Sandbox for a game that does this sort of thing very well.