next »

[michelmohr]

Sorry Michel I couldn't resist haha 
<snip>

Finally I fit in! Such photorealism!

[michelmohr]

Every Wednesday Pajama Llama puts out a blog post, and this week it was my turn as the Character creator tool I had been working on was pretty much finished. So here goes!

As an intern at Pajama Llama, I’ve had the pleasure of being tasked with creating a system for the artists to create characters in Flötsam. Juda-Ben and Stan needed a way to preview and generate different people quickly, by combining the multitude of body parts and clothing items they modeled. There are over 85 clothing pieces and 50 body parts spanning over both genders.

The most important part was to give the artists complete control over  how the characters look, which translated into a lot of drop-down menus and toggles.

Features
The characters are split up in several required body pieces: base body, hands, feet, head, eyes, mouth, nose, ears. The rest are non-required appendages, such as hair and clothes.

The clothes were definitely the most difficult to get right in terms of probability distribution, as the artists wanted to reduce the chance of characters being generated with non-matching shoes for example. This changed the requirement on the code side from two lists of objects (individual shoes), to one list of object pairs (shoe pairs). There are other items that are designed to go together, like certain sleeves and chest pieces. These can be manually mixed and matched to give a more granular control over the final look (for example using the sleeves of an overcoat with a simple tank-top).

To create further variation, I created a dyeing system as well: a global list of dyes can be defined, and then applied to the clothing pieces using a ShaderForge material. From this list of dyes, colours can also be flagged to not be used for certain items. So for example purple can be excluded from ever appearing on shoes.

Since the characters are rigged, all the limbs have bones that need to be taken into account so the clothes move along with the character. This also means the artists can actually preview their animations in-engine, using this tool instead of external software like Blender.

So the tool serves a twofold purpose: a testing tool for the artists and a character generator to be used in code by programmers!

A few colour variations of the same outfit.

Technical implementation
Body parts and clothing pieces are normally stored as lists of individual objects, with the exception of items that go together. Things like pairs of shoes and cool outfits, have a separate piece of code to make sure they stay together. Character parts are divided into Body and Clothes. While this division makes sense semantically, it also allows for the artists to define a range of looks for different archetypes, like drifter or trader, and generate people using only those ranges of items. The separate body selection of objects also allows them to increase diversity by creating characters of different ethnicities, and with different facial features.

I added a randomize button as well, the constraints of which can be arbitrarily defined and tweaked. An example of this is the possibility to set the chance of women wearing stockings when they’re also wearing shorts. These rules can of course be ignored and characters can be manually created, so I’d say control is entirely in the hands of the artists.

The data structure for the character generation.

The data structure for saving characters. (excluding dyes)
All these options are visualised to the artists using Unity’s custom inspector system. The features are divided into: character generation, setting the object lists, tweaking the rules and percentages, and finally animations testing, which scans the selected character animator for all available animations per layer.

While the artists are creating a character, all their selected options are saved to a CharacterLooks file, that holds the indexes and the ranges of items to be picked from.

This CharacterLooks file can be saved to a presets folder, making it possible to continue working it later or to be used when generating a character from the code.

 

The result
After 4 weeks of working on this not only have I created a useful tool that will speed up the creation of vastly diverse characters for Flötsam, but I’ve also learned a ton about Unity.

I had never heard of ScriptableObjects, and how powerful they are for saving settings before, and I’ve already starting using them in personal projects. Animations in Unity were something I had experimented with in school, but beyond that I had no idea how the bones/avatar system worked in Unity. Now I’ve had to get down and dirty with bones being transferred from one Animator to another, which makes me feel much more confident about dealing with Animations in the future.

For my graduation project I had worked with the inspector to make a Unity tool, but not on a project of this scale. I discovered a ton of functions that make the inspector so much more usable. (Did you know there’s a EditorGUILayout next to the GUILayout? I didn’t!) I also learned some hacks, such as using a box with height 1 and auto-width to create a nice divider line.

The character generator, with the different tabs shown next to each other.

[wazeau]

Greetings! Time for a little environment update.

In this post I’ll tell you more about the surrounding environment of your town, instead of focusing on the town itself like we did before.

One of the defining aspects of Flotsam is probably the fact that your town is always moving similar to a huge floating island or boat. This makes the game different compared to other city-builders, where you usually have fixed places of interaction, like forests to chop for wood or blue crystals to mine for space dollars. In Flotsam anything interactable is constantly passing you.


Examples of different points of interest.

While moving around you encounter certain environmental features we like to call “Points of Interest”. All these points will either contain parts and materials to salvage or have creatures or people living near them that provide food and other things. You’ll have to act fast because your window of opportunity with each will be small, as you float by with your town.


Houses could either be floating around or stuck on the ocean floor. These are mostly based on european architecture.

Because the whole world is flooded, most of the old world  remains under water. But some locations still have features sticking out of the surface, like tall buildings. This old world is based on the world we live in today. Because we want a big focus on recycling in Flotsam, there’s going to be a lot of garbage islands, wreckages of boats and other vehicles to salvage and even repair. We’ll tell you more about these later.


Example of a few wreckages.

The old world will occasionally be visible through the water in the form of cities and industrial areas. Some of them might even have skyscrapers, chimneys, pylons or viaducts sticking out of the water. Right now I’m basing these on European architecture. As we’re not really aiming for realism in Flotsam, I’m taking some creative freedom here by taking cool-looking older structures over structures that would actually be sticking out of the water like tall rectangular skyscrapers.

All of these structures will show what the player can expect to salvage from them. For example, viaducts with vehicles will contain lots of metal and fuel.
Urban buildings can have giant mussels growing on top of them which the player can collect, next to the usual scrap.
If traders or refugees are located at a point of interest you’ll notice this by their boats, flags and lights.


Viaducts could provide you with carparts, fuel and metal. Some animals could use them as “beaches” to live on.

Huge disasters occur when you collide with these! Thankfully there will be ways to maneuver your town, like with tugboats for example. This is still something we have to test thoroughly so I won’t share too much about this aspect yet.

Art wise it’s a big challenge to make environments interesting for Flotsam. Even with some of the beforementioned features we’ll still need some variation in the environment to keep the player interested. A vast blue sea without islands could prove to be very boring after a while. On the other hand designing the whole underwater world would take ages for only 1 environment artist.

I’m currently thinking of testing out very low-poly and low-detail models to create the underwater cities, because these will be hard to see for the player anyway. Making them modular and procedurally generated shouldn’t be too hard when working with simple shapes.
Subsequently I can put more time and detail into the surfaced features.

I’ll share more about the art of these city features when I’ve tested things out and when I can show some actual 3D/in-game shots, in a later post.

[JobLeonard]

How will you avoid that players get "stuck" on drowned buildings (perhaps on purpose to anchor their village)?

[wazeau]

How will you avoid that players get "stuck" on drowned buildings (perhaps on purpose to anchor their village)?

Puh! Ye this is a tricky one
We're not sure yet if we want to allow anchoring or being stuck, since it removes one of the main features of the game. I think we'll need a lot of testing to know this.

Anchoring your base might be possible in some way. The problem the player would have with anchoring could be that you don't get enough food to keep your people alive or resources to expand your town. A stuck base could also be a bigger target of hostile people and creatures.
One thing we know for sure is that smashing into one of these points of interest will destroy or damage parts of your town.

[Juwdah]

Seems like we forgot to post the SS.

Here's the concept Wazeau made for the fisherman's Hut, which will be an important building in the game

[Zorg]

Seagulls would love that all-you-can-eat fish buffet.

It looks great!

[Bombini]

Those are lovely concepts with a lot of soul!

[crushingcups]

Hi guys, here's a write up of what I've been working on for the water, you can read it on our site here.

In this blog post I will cover the different approaches I took for defining the look of the water in Flotsam. Some attempts worked better than others, and some were just good learning experiences. At the time of writing this, no final decisions have been made regarding what approach will be used: nothing that will be covered in this post is guaranteed to be in the game, but I decided to write up what I’ve learned so far for posterity’s sake.

The first attempt: shader
The most defining aspect of the water, as I understood it from the concept art and pre-production documents, is the foam. Foam around objects is an easy enough effect to achieve inside the shader, the problem with this however, is that the outline is only drawn over the object’s mesh, meaning its visibility depends exclusively on the angle of the camera. This is no good because we need something that’s visible from a top down perspective.

The second attempt: mesh
After spending some time studying shaders and trying to figure out if the effect I had in mind was possible with them, I had the idea to try a mesh based approach: this came down to calculating the intersection points between the segments of the mesh and the water plane, and here is what it looked like.

As you can see the shape of the mesh affects the shape of the foam, meaning sharper objects have more jagged looking foam. I decided this wasn’t a deal-breaker yet, so I continued fleshing out this approach. Here is a gif of what it looked like at this point:

The next problem was that the water plane isn’t exactly a plane: waves move and deform the entire mesh. My intersection solution worked fine with a simple plane, but once I started using individual triangles instead, the framerate dropped considerably because the calculations were too many to carry out every frame. I decided to continue working on it, figuring it would be better to get something working inefficiently and then optimize it, than having something fast and generic looking. This is what that looked like:

Still happy with this approach, I decided it was time to improve the look of the foam, so I began looking into UV solutions and texturing to give the artists more control over everything. Here is what it looked like with a simple texture with different blues.

I also looked into smoothing the foam mesh, which I succeeded in doing by calculating the angle between every three points, and adding another vertex in between if the angle was below a certain threshold. At this point I decided to take a step back and re-evaluate my options because a lot of intensive calculations were happening every frame for an effect that ended up being quite rough. Also after trying in the current build, calculating intersections ended up proving not to be practical, so it was time to try something else.

The third attempt: particles
I started experimenting with particle emitters attached to the objects, trying to avoid having to calculate the intersection points. The results with just a simple sharp circle as the particle shape looked like this:

The advantage of a particle based approach, is that I could rely on the fact that emitters simulated in world space would react to their environment. More specifically, the foam would linger slightly behind objects as they bob through the water making everything look much more organic. Additionally, being a particle system, the artists can really play around with all the settings and tweak everything until it’s just right. The downsides however, are that every object would need its own particle system that reflects its shape: a long plank would need a different setup than a round buoy for example.

Simple round particles weren’t gonna cut it though, so I started thinking about how to make the effect more interesting. I decided I would revisit an effect that has been around since the early 1980s, called metaballs. Metaballs are organic looking blobs that seemed like they would fit the feel of the foam properly. This is essentially how metaballs behave:

This effect can be obtained by overlapping two sprites with a soft blurry edge, and flooring the value to a certain intensity. I thought this would give the foam a nice blobbiness, and the foam of nearby objects would mesh together nicely.

The first way I thought of creating this effect was to use multiple cameras, one that renders everything but the particles, and one that only renders the particles and applies the metaball image effect. While this worked in theory, compositing together multiple cameras gave me a lot of problems, mainly with depth. The way I ended up doing it made use of the stencil buffer available inside the shader. Basically I mark all the pixels rendered by the particle system, and only apply the image effect on those pixels, effectively removing the need for a second camera. This also allows me to do things like not render the water inside the boat without needing a shader mask and a separate plane. Here is what the first tests looked like:

At this point it started being time to implement my solution in the current build of the game. I struggled with creating a particle emitter in code for every object, because a lot of the options don’t seem to be accessible anywhere but the inspector itself. So in the end I made a prefab of the foam that I am instantiating as a child at the position of every object.

After various tests and succeeding technically in doing what I wanted, it turned out that the effect didn’t end up looking like what I had in mind:

Between not being subtle enough and the fact that particles linger behind and sometimes hover in the air when the waves move objects down, we decided yet again to try something else.

The fourth attempt: animated textures
This is the current approach I’m working on. It revolves around using textures like spritesheets, to get an animation within the texture. I decided that working as much as possible within the texture will help avoid a lot of problems that stem from the fact that the water moves. A texture moves with the water, so my gut tells me there is something worth exploring there. Here is an early picture of my experiment:

The idea is to make the water more interesting with textures as opposed to simulated foam, and perhaps use the initial depth shader solution in combination with this approach.

Conclusion
The perfect approach has yet to be discovered, and it is more than probable that it will end up being a combination of the above attempts. The water is a very important aspect of Flotsam. Thus it’s likely that it will take some more time to settle on something that is to everyone’s liking while still being performant enough and viable for the game. That’s it for this week, stay tuned for more!

If anybody has any suggestion's we'd be delighted to hear them!

[JobLeonard]

Maybe you could exchange notes with the Eat Create Sleep team

[Juwdah]

Maybe you could exchange notes with the Eat Create Sleep team

I've checked it but I'm afraid it's something entirely different they're trying. I'm going to followup on their progress though!

[io3 creations]

If anybody has any suggestion's we'd be delighted to hear them!

Intersting approaches.

Thanks again for the intersetion link.   My slicing code is coming along nicely and I know that I'll be facing similar issues with that as well as other features that I want to implement in various games.  Is it better to go with mesh or modify the texture somehow?

A few suggestions that you may find useful.
Having to find intersection and generate new mesh every frame is certainly not the most efficient way.  By creating indivicual triangles, do you mean creating separate triangle objects or creating triangles but still adding them to the same mesh?  I've just started looking mesh creation in Unity and for my sliced objects that approach will work well.  Of course, I also will have to "fill in" the sliced part but for your 2d wave mesh that wouldn't be needed.  Then, once you have the mesh, you can update the vertices as needed.  Depending on the approach used, this wouldn't exactly follow the actual shape of the intersection but for a cartoonish style would allow for that. 

The question is, how to determine (or to be more efficient, approximate) the intersection.   My first guess would be to create some kind of "voxel" 3d array for the shape of the object in water.  Then, given your wave, you can use the voxel array to figure out the intersection and use that for drawing foam mesh (hopefully makes sense).  If needed, it should also be possible to make sure that each point of the foam mesh is always above the water.  Although, as I'm trying to visualize it, it might work if some parts dip below the water as well.

For the particle effect, instead of changing size/radius, you could also fade them away.  Changing transparency might be a bit more processing intensive so changing color (from white to blue) could be more efficient and might also give different effect/style.

The animated water reminds me of how cartoon animations and agree that it has potential with the game's style.   What comes to mind is as the foam spreads around the boat, as it becomes larger "holes" start formingm in it and the shape disintegrates.  If you can check out various animations and see how they do it.  I recall that effect more for behind faster moving ships and boats but something similar might work around relatively sationary object.  The issue would be: is it possible to combine the two textures (i.e. the sea in general and the foam around objects) into one using it on one single mesh or better to have another mesh "on top" of the water for the foam.  I've seen the second approach being used for animating character eyes with a separate mesh.  Though in your case, one issue would be to make sure that the transition between the lines/shapes that are on the sea and the ones from the foam looks good.  If you go in that direction or have thoughts about it, let me know as I'll be also facing similar issues later.

[Pixelologist]

I'm looking forward to buying then playing this. It's wonderful.

[crushingcups]

Intersting approaches.

Thanks again for the intersetion link.  My slicing code is coming along nicely and I know that I'll be facing similar issues with that as well as other features that I want to implement in various games.  Is it better to go with mesh or modify the texture somehow?

No problem, glad to help. I'm not really sure what you mean by going with mesh or modifying the texture, but I would look into remapping the UVs for the two separate slices of the object and still use the same texture, if that's what you mean.

A few suggestions that you may find useful.
Having to find intersection and generate new mesh every frame is certainly not the most efficient way.  By creating indivicual triangles, do you mean creating separate triangle objects or creating triangles but still adding them to the same mesh?  I've just started looking mesh creation in Unity and for my sliced objects that approach will work well.  Of course, I also will have to "fill in" the sliced part but for your 2d wave mesh that wouldn't be needed.  Then, once you have the mesh, you can update the vertices as needed.  Depending on the approach used, this wouldn't exactly follow the actual shape of the intersection but for a cartoonish style would allow for that.  

What I did was just clear the mesh's triangle array and create a new one every frame, so not really creating new objects. You should check this out for your mesh splitting stuff. He solves the texturing of the filled in sliced part too if I remember correctly.

The question is, how to determine (or to be more efficient, approximate) the intersection.   My first guess would be to create some kind of "voxel" 3d array for the shape of the object in water.  Then, given your wave, you can use the voxel array to figure out the intersection and use that for drawing foam mesh (hopefully makes sense).  If needed, it should also be possible to make sure that each point of the foam mesh is always above the water.  Although, as I'm trying to visualize it, it might work if some parts dip below the water as well.

For the particle effect, instead of changing size/radius, you could also fade them away.  Changing transparency might be a bit more processing intensive so changing color (from white to blue) could be more efficient and might also give different effect/style.

The animated water reminds me of how cartoon animations and agree that it has potential with the game's style.   What comes to mind is as the foam spreads around the boat, as it becomes larger "holes" start formingm in it and the shape disintegrates.  If you can check out various animations and see how they do it.  I recall that effect more for behind faster moving ships and boats but something similar might work around relatively sationary object.  The issue would be: is it possible to combine the two textures (i.e. the sea in general and the foam around objects) into one using it on one single mesh or better to have another mesh "on top" of the water for the foam.  I've seen the second approach being used for animating character eyes with a separate mesh.  Though in your case, one issue would be to make sure that the transition between the lines/shapes that are on the sea and the ones from the foam looks good.  If you go in that direction or have thoughts about it, let me know as I'll be also facing similar issues later.

I've thought of using another mesh on top of the water as well, like the eye thing you mention. I think I'll end up renouncing approaches that require calculating intersections though because it seems like it will be too expensive for the scale of the scenes we have in mind. The approach I'm experimenting with now is to use some kind of inverted and clamped ambient occlusion as the foam. The results are pretty promising but the only problem is that it's effectively a post processing effect (SSAO) because I haven't found any way of doing it in world space, so it's still view dependent. Here's a picture that shows it, check out the top of the raft, ideally there shouldn't be any AO there.

I'm also trying to figure out how to have more control over the color of the AO, if I return white instead of black there's no occlusion cause black denotes occlusion and white denotes no occlusion. Another thing I'm concerned about is the aliasing going on because of the clamping and I'd like not to have to use another post effect to fix that.

[io3 creations]

Intersting approaches.

Thanks again for the intersetion link.   My slicing code is coming along nicely and I know that I'll be facing similar issues with that as well as other features that I want to implement in various games.  Is it better to go with mesh or modify the texture somehow?

No problem, glad to help. I'm not really sure what you mean by going with mesh or modifying the texture, but I would look into remapping the UVs for the two separate slices of the object and still use the same texture, if that's what you mean.

Oh, that last sentence was part my "general overview" and was actually about your project and not about the slicing. Whoops.

What I did was just clear the mesh's triangle array and create a new one every frame, so not really creating new objects.

Oh, I see.  From what I understand, wouldn't Unity will still have to update the normals and do other things (e.g. vertex optimization)?  That could add up.  If you "simply" modify the vertex positions of the mesh, then those extra steps shouldn't be necessary.

That approach could be used with your original intersection based mesh approach.  But instead, you just create a mesh at the beginning and update the vertices to create the outline.  Or use a larger than needed mesh and use the initial vertex info to create/draw a texture that surrounds the object in the water.

You should check this out for your mesh splitting stuff. He solves the texturing of the filled in sliced part too if I remember correctly.

Lol! Just finished my slicing engine before reading your post.  Though it was good to learn a few more things about how Unity works (Quaternions are sure fun! ).  Interestingly, I did look for such info about a year ago found some Constructive Solid Geometry type resources. There's also a slicing asset TurboSlice and and extended version for meshes with skeletons so the mesh can maintain proper animation after being sliced for both sliced parts.  Interestingly, I haven't come across the link you mentioned.  Perhaps I was looking more for "slice" than "split".  I know some people tend to use for the same idea but for me splitting is similar to shattering or breaking into many pieces from a given point than having a nice clean slice.

Actually, the mesh splitting demo doesn't fill in the slices - at least not yet.  It's mentioned under The Goal http://danni.foxesgames.com/projects/m-sc-games-technology/procedural-mesh-splitting/  and may be in the code but the demo doesn't wrapped the texture "exactly".  That issue isn't noticeable for most objects but it becomes very apparent for the exact same object that I was thinking about testing: watermelon.  The first slice is good as it shows the inside of a watermelon, provided you slice near the center.  But if you keep slicing then the issue becomes apparent as the texture won't be lined up properly to resemble a watermelon - i.e. the green shell won't be aligned to where it should be.  The demo is here: http://danni.foxesgames.com/2011/10/02/slicing-tech-demo/   I've thought of the ways to deal with it and there are a few extra things you need to consider based on what kind of internal structure you want to show.

[crushingcups]

If you download the project I linked and run the demo scene, you'll see the slices are capped. I believe the demo you tried is older. The problem with moving vertices rather than recreating the triangles, is that depending on how much of the object intersects the water, more or less foam triangles (and therefore vertices) are needed. I'm getting good results with the SSAO approach, so I think I'll probably be sticking to that for the time being.

[Juwdah]

Hey guys, here's a write up on the design process of the fish.

Designing sea creatures part 2:

Designing doesn’t always go smoothly. There are many brick walls, times you’d hit your head against the wall and moments where you keep telling yourself to rework everything. For the friendly, regular fish in Flotsam, I’ve gone through every one of these phases.

These fish don’t affect gameplay as much as other aspects of the game, but they provide a valuable visual addition, as they’re one of the main moving environmental features that tie the mood together. Here’s how I designed a small part of the living environment of Flotsam.

The first sketches

When we started Flotsam, we explored a lot of different styles, in search of the perfect aesthetic. Every illustration or sketch had to capture the essence of the world we wanted to portray. Putting what we had in our minds to paper took a lot of exploration to get just right. While our priorities lied with the core components of the game, like buildings and characters, fish occasionally found their way into the brainstorming process.

I started off with a basic mood-board of regular and exotic fish familiar to everyone. I then iterated upon these designs over and over, refining them as I went. I hoped to find a fish that fit all the ideas I had about what feelings Flotsam should convey.

first, more realistic sketches

The first sketches I made were very realistic, but they quickly felt too bland: nothing about them was memorable. This was the first layer of exploration I had to get out of the way before eventually finding more interesting aesthetics. I played with the anatomy, enlarging the eyes and simplifying the body shapes, playing dress up with different kinds of fins. I mixed and matched other animal and insect parts to create fun concepts, like this guy below who’s head is inspired by a beetle’s shell.

style test: beetle fish

Unfortunately, nothing good stood out: these fish just didn’t speak to me the way I had hoped. I still wasn’t happy with the style, and decided to explore it further, but for now I moved back to concepting more pressing parts we needed for the prototype.

In between

While working on the first prototype, inspiration suddenly stuck me with a pleasant fish design. Since the human characters for the game were starting to take shape, this carried over to the fish as well. A small unrelated inktober sketch gave me some ideas, and finished character concepts involving fishing gave me others, but the most consolidating moment of all, was when I was busy designing the huge whales. After a couple of more sketches I was set: I knew what the fish were gonna look like.

in-between development, new fish designs sprouted

The whales and how they sparked an idea

As with fish, I tried combining some of the whales with other animals, which gave birth to odd but interesting combinations. As well as adding large fins and tusks to see how far I could push the quirkiness. Some of these we truly liked: the dog-whale seemed like an interesting concept to take further, and was received positively when we initially showed it.

whale designs we already showed

But it’s only when I drew the whale that got stuck in a subway car and grew within it, that an idea dawned upon me. To fully maximize the effect of Flotsam’s over-arching theme, we need the wildlife to live in symbiosis with the garbage. As it’s not only important to human survival but marine fauna as well.

the whale that sparked an idea

The friendly fish of Flotsam

The time finally came to sit down and get back to designing the friendly fish once again. The idea had sprung, the base was set: now all I had to do was put it on paper. After a couple of odd tries, I finally cracked what we wanted to achieve with the small friendly wildlife that will entertain the water. Here’s some of the sketches:

Final designs

The roadblocks we came across here were mainly focused on readability, as we don’t want the player to be distracted by small fish, but still incorporate trash and garbage in the design. The next step is going to be making 3D models based on these sketches, and iterating on them once again to solve the problems that will inevitably arise from the switch to three dimensions. I honestly can’t wait to see these guys swim!

On the gameplay side this decision had effects as well: now it makes sense to receive small amounts of trash from catching fish. This will also allow us to balance survival and building subtly, for example by reducing the amount of food a particularly contaminated fish gives. It also helps to blur the lines between various resource types, like food and scrap.

We’ll have to see where this approach takes us, but here are some sketches that explore the possibilities for modularity within the fish models. The fact that all these different heads have parts covering the neck area, means they are more easily applicable to other bodies. Without having to worry about ugly seams or problems with smoothing groups/UV’s.

modularity tests

Wrap up

Fish are not the only creatures that will receive this treatment of integration with their environment: I have many ideas on how to apply this principle of merging with garbage and waste in other marine beings. In the world of Flotsam, now that the environment has become unfruitful, new and unexpected symbiosis will emerge between water creatures and their surroundings that I can’t wait to share with you all! Stay tuned for more and thanks for reading!

[io3 creations]

The problem with moving vertices rather than recreating the triangles, is that depending on how much of the object intersects the water, more or less foam triangles (and therefore vertices) are needed. I'm getting good results with the SSAO approach, so I think I'll probably be sticking to that for the time being.

You're right, I was mainly thinking of having an object with predictable wave intersection. That will certainly change if the object is non-uniform or if it turns over. But the vertices could be useful as an approximation that could be smoothed out properly with if a continuous outline is drawn .

I looked into SSAO a bit but am still in the learning phase so I may be way off with some things.  To avoid the issue at the top of the raft, perhaps the depth or z-buffer could be used to consider the only points where the depth difference is below a certain value.  Or is that what you already did?  Shaders are another area for me to look into so I'm not sure how it would actually be implemented.

If you download the project I linked and run the demo scene, you'll see the slices are capped. I believe the demo you tried is older.

If by capped slices you mean that there's a mesh added to sliced area, then yes, that part is also in the demo. What I was referring to is another aspect where the texture wrapping looks exactly like the internal structure of the object.  When you slice a real watermelon, you'll see different shapes.  Some will have more red for the inside and little green for the rind.  If you slice only the rind, then the entire sliced area should be green.  The demo on github only has a box and a cylinder but no watermelon so I can't check.  Based on the description on the page, I don't think that type of precise texturing is implemented as that would need to be customized for different objects with different shapes and internal structure that also depends on the slice location and angle.   But I have a few ideas to deal with that.  One is a simple slice location and angle based approximation where you simply select the relevant predrawn texture.  The other is similar to your object/wave intersection.  Have certain 3d meshes that represent the internal structure and slice those as well.  Once the intersection line found, the sliced internal parts can be drawn to the sliced area texture.  Since slicing would only take place once in a while, that should be acceptible and could give a better and consistent look.

[The_Observer]

We recently added context-sensitive cursors to the game. I'm planning to write a small article about it coming Wednesday.
If you've got any questions or thoughts on it, let me know! I might include them in the article.

[io3 creations]

We recently added context-sensitive cursors to the game. I'm planning to write a small article about it coming Wednesday.
If you've got any questions or thoughts on it, let me know! I might include them in the article.

One common way that comes to my mind for such an approach is raycasting.  But depending on gameplay, it may be possible come up with an optimized approach.  Perhaps colored bitmap areas or even projected vertex/polygons could be useful.  Or is your approach different?