Design and implement a dynamic membrane rendering around microbes

[jjonj]

This will be very difficult and will require quite some experience with ogre/graphics I imagine. The way to do it will probably be vertex buffer modification through ogre based on the hexes in the microbes compound scene node.

[jjonj]

It would be nice if the solution used here could also be used for displaying compound and agent clouds in the enviroment.

[Alexthe666]

I think that the player should design the membrane by clicking and pulling with an option enabled (otherwise people would be just moving hexes around...)

[Alexthe666]

How about we design the cell with empty hexes first, then add organelles (this also allows for multi-hex organelles).

[patowen]

One possible way to do this is to use metaballs, centering each metaball at the center of each hex. The trick would be to find a good threshold so that the cell is not too bulky, but each individual hex is not visible. I believe that such a threshold exists, though. The mesh would then be created with marching cubes. I do know how to do 3D modelling vertex by vertex pretty well, but I am completely unfamiliar with the OGRE API.

[TheGuineapig]

@patowen95 maybe it could do this by default and the user can edit the membrane in the editor.

[jjonj]

I am fairly familiar with ogre but not at all with vertex-by-vertex (except for some very simple openGL) so it would be great if you would be willing to try some stuff out! Here is the relatively short intro guide to ogre http://www.ogre3d.org/docs/manual/index.html#Top with section 5 being about hardware buffers, which should be what you would need!

[patowen]

I may try it out. I am kinda swamped at the moment with other work, but once that is over, I could start experimenting.

As to allowing the user to edit the membrane, I will consider it. One possible method of doing this is to allow the user to adjust the parameters of the metaballs, which could make the cell thicker or thinner in the third dimension. As I do not have something to play around with, yet, I can't be sure what the nicest method would me.

I think this has been mentioned before, but I believe that the best way of editing the cell would be to start with creating empty hexes, which shape the membrane, and then put organelles inside those empty hexes. Once the membrane is transparent and smooth, and organelles have models, it will be confusing for the membrane to reshape everytime the user puts an organelle in an empty space. That should be an invalid operation.

[jjonj]

Sounds good patowen, I agree on the editing method!

[Alexthe666]

I agree 100% patoween, first empty hexes than you can put organelles in them!

[TheGuineapig]

I agree but I don't like the idea of the cell being all blobby. I think that you should be able to drag the membrane to make more shapes. Have you ever used liquify on photoshop? That is kinda what I mean. It would be cool if you could just mess about with the membrane. Also, whatever happened to the skeletal idea? Attaching skeletal parts and have the membrane form around it dependent on the size of the 'bone' sections.

[patowen]

@Rabiesguineapig, I understand your concern. Metaballs generally make things blobby. However, I believe after I play around with it, I can adjust parameters to, for instance, flatten the metaballs. In addition, the cell may end up being 40 or 50 hexes rather than 8 or 10 like it is now, which should allow more flexibility with the shape. Again, since I do not have anything to play around with, yet, I cannot know for sure if a liquify-like tool will be desired. It should be possible with a variation of metaballs, anyway.

As for the skeletal idea, I believe it is incompatible with the hexes. I joined the project after hexes have already been decided upon, so I am not sure how people decided on it.

When I work on the membrane design, I will test it to see if cells are customizable enough, and I am relatively confident that the hex version can be as nice as the skeletal idea.

As for messing around with the membrane, remember that the screen is 2D and cells are 3D. Simply being able to drag vertices of the membrane around does not yield as much flexibility as you might think.

[Oliveriver]

There's a test algorithm Nimbal posted ages ago on how the shape of the membrane might be created. I don't know if it's relevant anymore but I'll try and find it.

EDIT: Found it - http://thrivegame.forum-free.ca/t1031p135-building-microbe-stage#24200

[patowen]

I will keep that information in mind. It should still work with my approach, but I will definitely have to tweak it to make the hexes invisible.

Since I am unfamiliar with C++, Ogre and CodeBlocks, I have decided to do my experimentation in Java. I am highly familiar with Java, Eclipse and OpenGL (namely JOGL), and the logic should be roughly the same when it is time to port it into C++. I think it will be faster for me to work with Java and remake it with C++ once I am satisfied. Let me know if you have any objections. I plan on using YouTube to share my progress.

One question: Should we allow cells with a hole in the middle? I don't know of any cells IRL that are shaped like toruses. Red blood cells come close, but they have a dent, not a hole. Enforcing a lack of holes in the editor is as simple as filling them in if and when they are created. That being said, allowing holes may allow for more creativity. We have to be careful, though, about making sure the user cannot exploit holes and put a flagellum inside the cell.

[jjonj]

Sounds like a good idea! Note that the

One question: Should we allow cells with a hole in the middle?

I'm told, no.

Found it

I should really read through that thread

[TheGuineapig]

I'm told, no.

Does that mean that we can't have compound gatherers?

[jjonj]

Does that mean that we can't have compound gatherers?

You mean odd shapes protruding from the body of the microbe? I think they would be fine, but they would have to be balanced somehow.

[TheGuineapig]

maybe they could only extend a certain amount before they would break off the cell and it would 'bleed' cytoplasm to death.

[patowen]

One issue I find with the algorithm is the cell is assumed to be 2D, which it is not. I have worked a bit on the membrane, and I will post an unlisted youtube video of it once I smooth out the bumps.

[patowen]

Here is my current progress: https://www.youtube.com/watch?v=W20rDBK70_0

I plan on making it a bit more dynamic and allowing the membrane to bulge outwards a bit more. The tricky part is doing that while still making straight lines smooth.

[TheGuineapig]

Wow that's great! Maybe try to make it smoother so it looks less hexagonal

[Moopli]

Maybe by increasing the thickness of more internal sections -- so a 7-hex 'circle' is thicker enough in the middle that it looks more round than hexagonal, and a 15-hex circle even more so. (oh is that what you mean by bulging?)

[jjonj]

Well the membrane doesn't need to fit a hex shape, everything inside it will just be aligned by hexes.

[TheGuineapig]

Jjonj would it be possible to encorporate hexes and skeletons by having organelle fitting into hexes but have an editable membrane skeleton to fit around the outside? That way, more creative cells can be made while still keeping it simple with hexes. Also, I think that if it is going to be organelle per hex then there will be some problems. Cells would become very big and clunky very quickly. I have some solutions: Hexes are divided into triangles that can have an organelle each. [Medium] Hexes are smaller than they are now in proportion to the screen size and other options. [Easy] (Corresponds with previous) Hexes can have up to 3 of the same organelle inside eg; 3 chloroplasts in a hex and a nucleus in another.[Harder] You can edit the hex/tri sizes in the cell editor.[Difficult]

[patowen]

I believe that we are going to have smaller hexes than we currently have. I used a small grid for the video for testing purposes. The idea of being able to edit the membrane skeleton by hand is a good idea, and I will try to incorporate that.

[jjonj]

I believe that we are going to have smaller hexes than we currently have.

Yep, thats what I imagined as well.

[TheGuineapig]

This is what I had in mind. Just made a quick visualization. Obviously the actual GUI of the editor needs further discussion.

[Moopli]

NURBS then? What about the surface of the cell? We could just revolve the user-made curve around the axis, but I can think of a few cases where the resulting surface of revolution will look odd (imagine giving your cell fins of a sort only to find that it now has a ridge all around it) There's probably a better way though.

[TheGuineapig]

I don't know what Nurbs are. I'm just going to nod my head and pretend I understand.

[Moopli]

NURBS stands for non-uniform rational B-spline — a useful kind of mathematical curve representation. You may have heard of Bezier curves, NURBS are a generalization. Anyway, I can think of a few better ways to turn an outline into a believable surface, but they're not too pretty to implement...

[TheGuineapig]

Well luckily for us we don't have a deadline. It isn't too hard is it? Another tricky aspect of this would be putting pilus and flagella on the rendered surface. Hitbox will also be an issue

[Moopli]

Those are almost trivial compared to creating a good surface, actually. Either way I don't see anything wrong with the implementation @patowen95 has going, so if you want me to elaborate we can go to the forums

[patowen]

I'm going to stick with my approach for now, as it seems to be working. The main downside is that I have to deal with rather tricky constraints to make sure that straight lines are not bumpy. Once that is fully implemented, it should be possible for the user to indirectly affect the shape of the membrane by adjusting parameters for each hex. Unfortunately, until I code it and experiment, I will be unable to tell what options we actually have, but I'm sure it should be possible to displace the vertices in the resulting mesh to further customize the shape.

[jjonj]

Any progress on this patowen?

[patowen]

Unfortunately, I have been too busy to really work on it at the moment. If you want, I can post the Java prototype I have at the moment so that more people can at least look at it.

[jjonj]

No problem and no real rush, It was just suggested to have this in for the next release on the forums which I dismissed as a bit too optimistic, so just wanted a general update! If you think you'll have more time within a month or two you don't really need to share it, as it will take me a long time to get into everything related, but perhaps moopli would want to take a look at it sometime, although he's working on fluid dynamics atm.

[Moopli]

@jjonj is absolutely right, I'd love to take a look. Getting your Java prototype translated, even with the current constraints (which can be tweaked once it's in the game), is probably best since we can start testing in-game.

[patowen]

Alright. I'll either send a Dropbox link or post it on GitHub, depending on what I decide. It will require JOGL to run. (http://jogamp.org/)

[patowen]

Here is the link to the src files. Let me know if you have trouble running it. Sorry for the delay.

https://www.dropbox.com/sh/md3v89ebmwapatb/AADJLm8-7tG1A-Dp5YZSswnta

[jjonj]

I had a look and was wondering if would be feasible to smoothe out the overall surface on top of the metaball calculations, since we often get some rather jagged-looking edges when the membranes turns and doing straight lines aren't possible in some directions. An alternative solution could be to allow the membrane to be placed without the hexagon restriction, which would allow everything to be perfectly smooth I believe, but that would need some other restrictions.

[patowen]

Yeah, designing metaballs to work with a hex formation is quite tricky. Unless the metaball formula is picked very carefully, a straight line will have obvious bumps. I designed it that carefully, but in other situations, it is not smooth enough, and the hex source is quite obvious. One possible idea, as you suggested, is to allow the user to set the membrane without the hex restriction and then use hexes to place organelles (Only hexes inside the membrane are available for use).

Of course, there is always the option of dropping hexes entirely, but I would be very careful about making backward progress like that.

[TheGuineapig]

I agree with a customized membrane. Remember this concept? http://www.moddb.com/games/thrive/images/cell-editor-ideas#imagebox Especially if its easier than hexes!

[Moopli]

I had a chat with my super at work, and he suggested using metaballs, with some extensions:

• I told him I was worried about flatness, and he suggested we do something like scaling each metaball radius by the distance to the edge.
• Since we're also worried about lumpiness making the hexgrid nature of the microbes apparent, he suggested we can apply some smooth displacement noise (along normals).
• And of course, we could always modify the metaball kernel
• Another awesome idea he had was to make the metaball radii slowly change over time -- since making the membrane morph slowly is one important way to make our microbes look like more than just moving bits of plastic, but alive.

[patowen]

Thank you for these ideas. I was having trouble figuring out what to do. The video I uploaded on YouTube was based on a modified kernel that was as smooth as possible. That being said, it included square roots, making it less efficient than I would prefer. Scaling by the distance to the edge sounds like a much better idea. I also like the idea of smooth displacement noise.

Since I implement metaballs with marching cubes, in game, it would probably be better if the mesh was precalculated, making the radii not change over time. To make the microbes look alive, displacing the mesh itself would seem like a better idea to me.

[Moopli]

Just what I was thinking -- displace the vertices along their normals. In general, the mesh generated by the metaballs should be smooth enough that we generally have a pretty wide range of displacement distances. For the morphing, I'd say we should generate a new noise map every once in a while, and interpolate from current positions to the next. For the noise map, I'd imagine a smooth 3D scalar (storing displacement along normal) noise function would be the way to go.

For the mesh generation, what sort of resolution are we going to use? I'm trying to figure out if higher-frequency noise is worth it at all.

Come to think of it, what we'd need is two noise layers -- one random delta to blob radii (applied not on metaball but on mesh), and the above lower-amplitude smooth 3D displacement noise. New deltas from the reference positions would be recomputed every now and then (at drastically different frequencies, to keep things interesting), and we'd smoothly interpolate. To keep the interpolation smooth, we'll want to store the start position of each smooth growth/shrinkage interval in addition to the target and current positions -- that way we can use a sigmoid function (Blinn-Wyvill, or the symmetric double-parabola, or something else similarly cheap) to interpolate, so changing target vertex positions doesn't result in jerky movement.

[patowen]

By the way, I'm not sure how much time I can put aside for this game, so if someone else feels like trying to implement this, that would not be an issue.

[patowen]

So, I just revisited the code base, seeing if I can start working on it again, but unfortunately, the setup script does not work for me. While trying to compile OGRE, a windows dialog appears saying that "cc1plus.exe has stopped working." Then, when invoking CMake, it says, "Required library OGRE not found! Install the library (including dev packages) and try again." with some more stuff. I will open this up as an issue, but it seems to be more of an issue with MinGW. Perhaps the setup script could contain some option to increase stack size, if stack overflow is causing the error?

Also, there is an assets directory in the git repository which is a bit confusing. I assume svn can just handle the stuff that git doesn't handle just fine. Let me know if this is incorrect.

[Moopli]

@jjonj has been working on porting your code, so you can at least take a look at what he's done so far. I'm afraid I can't help you with the MinGW script, though. The script might clone the SVN repo,but I'm not sure.

[patowen]

Oh, I had no idea that progress was being made on this issue. I saw your comment about the table being dynamically created, and I would agree with you that static is better. Java makes everything dynamic. If he doesn't fix it, I will (assuming that I can even set my code base up).

[jjonj]

Had any luck patowen?

[patowen]

I've managed to set it up, but I haven't worked on it. I seem to lose steam as soon as I go through the ordeal of trying to set it up. I'm also not sure whether the current algorithm I have in place is good enough, since it is not as efficient as I would like, and the resulting shape cannot easily be adjusted by changing parameters. A possible algorithm was given in the forums, but it just creates a 2D path, and as far as I know, there is no generic algorithm for converting that to a 3D mesh (besides making a cylinder or something like that).

The problem with metaballs is that unless the equation for them is very finely tuned, a straight line of hexes will create a bumpy cell surface. Perhaps when I have the time and energy, I may experiment with something else. I'll let you know if I find anything good.