New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design and implement a dynamic membrane rendering around microbes #115

Closed
jjonj opened this Issue Apr 5, 2014 · 74 comments

Comments

Projects
None yet
8 participants
@jjonj
Contributor

jjonj commented Apr 5, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jjonj

jjonj Apr 24, 2014

Contributor

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

Contributor

jjonj commented Apr 24, 2014

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

@Alexthe666

This comment has been minimized.

Show comment
Hide comment
@Alexthe666

Alexthe666 May 6, 2014

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 commented May 6, 2014

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...)

@jjonj jjonj referenced this issue May 6, 2014

Closed

Cell Membrane #136

@Alexthe666

This comment has been minimized.

Show comment
Hide comment
@Alexthe666

Alexthe666 May 6, 2014

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

Alexthe666 commented May 6, 2014

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

@patowen

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen May 7, 2014

Contributor

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.

Contributor

patowen commented May 7, 2014

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

This comment has been minimized.

Show comment
Hide comment
@TheGuineapig

TheGuineapig May 7, 2014

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

TheGuineapig commented May 7, 2014

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

@jjonj

This comment has been minimized.

Show comment
Hide comment
@jjonj

jjonj May 7, 2014

Contributor

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!

Contributor

jjonj commented May 7, 2014

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

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen May 7, 2014

Contributor

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.

Contributor

patowen commented May 7, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jjonj

jjonj May 7, 2014

Contributor

Sounds good patowen, I agree on the editing method!

Contributor

jjonj commented May 7, 2014

Sounds good patowen, I agree on the editing method!

@Alexthe666

This comment has been minimized.

Show comment
Hide comment
@Alexthe666

Alexthe666 May 7, 2014

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

Alexthe666 commented May 7, 2014

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

@TheGuineapig

This comment has been minimized.

Show comment
Hide comment
@TheGuineapig

TheGuineapig May 7, 2014

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.

TheGuineapig commented May 7, 2014

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

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen May 7, 2014

Contributor

@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.

Contributor

patowen commented May 7, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@Oliveriver

Oliveriver May 7, 2014

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

Oliveriver commented May 7, 2014

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

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen May 10, 2014

Contributor

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.

Contributor

patowen commented May 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jjonj

jjonj May 11, 2014

Contributor

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

Contributor

jjonj commented May 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@TheGuineapig

TheGuineapig May 11, 2014

I'm told, no.

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

TheGuineapig commented May 11, 2014

I'm told, no.

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

@jjonj

This comment has been minimized.

Show comment
Hide comment
@jjonj

jjonj May 11, 2014

Contributor

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.

Contributor

jjonj commented May 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@TheGuineapig

TheGuineapig May 11, 2014

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

TheGuineapig commented May 11, 2014

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

@patowen

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen May 11, 2014

Contributor

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.

Contributor

patowen commented May 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen May 11, 2014

Contributor

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.

Contributor

patowen commented May 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@TheGuineapig

TheGuineapig May 11, 2014

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

TheGuineapig commented May 11, 2014

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

@Moopli

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli May 12, 2014

Contributor

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?)

Contributor

Moopli commented May 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jjonj

jjonj May 12, 2014

Contributor

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

Contributor

jjonj commented May 12, 2014

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

@TheGuineapig

This comment has been minimized.

Show comment
Hide comment
@TheGuineapig

TheGuineapig May 12, 2014

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]

TheGuineapig commented May 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen May 12, 2014

Contributor

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.

Contributor

patowen commented May 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jjonj

jjonj May 12, 2014

Contributor

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

Yep, thats what I imagined as well.

Contributor

jjonj commented May 12, 2014

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

Yep, thats what I imagined as well.

@TheGuineapig

This comment has been minimized.

Show comment
Hide comment
@TheGuineapig

TheGuineapig May 14, 2014

image

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

TheGuineapig commented May 14, 2014

image

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

@Moopli

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli May 14, 2014

Contributor

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.

Contributor

Moopli commented May 14, 2014

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

This comment has been minimized.

Show comment
Hide comment
@TheGuineapig

TheGuineapig May 14, 2014

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

TheGuineapig commented May 14, 2014

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

@Moopli

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli May 14, 2014

Contributor

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...

Contributor

Moopli commented May 14, 2014

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

This comment has been minimized.

Show comment
Hide comment
@TheGuineapig

TheGuineapig May 14, 2014

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

TheGuineapig commented May 14, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli May 15, 2014

Contributor

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

Contributor

Moopli commented May 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen May 15, 2014

Contributor

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.

Contributor

patowen commented May 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jjonj

jjonj Jul 2, 2014

Contributor

Any progress on this patowen?

Contributor

jjonj commented Jul 2, 2014

Any progress on this patowen?

@patowen

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen Jul 19, 2014

Contributor

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.

Contributor

patowen commented Jul 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@TheGuineapig

TheGuineapig Jul 23, 2014

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!

TheGuineapig commented Jul 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli Jul 31, 2014

Contributor

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.
Contributor

Moopli commented Jul 31, 2014

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

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen Aug 5, 2014

Contributor

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.

Contributor

patowen commented Aug 5, 2014

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.

@jjonj jjonj added this to the Release 0.3.0 milestone Aug 5, 2014

@Moopli

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli Aug 6, 2014

Contributor

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.

Contributor

Moopli commented Aug 6, 2014

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

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen Aug 24, 2014

Contributor

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.

Contributor

patowen commented Aug 24, 2014

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

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen Dec 16, 2014

Contributor

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.

Contributor

patowen commented Dec 16, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli Dec 16, 2014

Contributor

@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.

Contributor

Moopli commented Dec 16, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen Dec 16, 2014

Contributor

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).

Contributor

patowen commented Dec 16, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jjonj

jjonj Jan 11, 2015

Contributor

Had any luck patowen?

Contributor

jjonj commented Jan 11, 2015

Had any luck patowen?

@patowen

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen Jan 11, 2015

Contributor

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.

Contributor

patowen commented Jan 11, 2015

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.

@jjonj

This comment has been minimized.

Show comment
Hide comment
@jjonj

jjonj Jan 13, 2015

Contributor

Sounds fair enough! Efficiency isn't too big of a deal when doing stuff in the microbe editor and regarding bumpy surfaces then we talked about not having to align the cytoplasm in hexes, I'd imagine that this would help!

Contributor

jjonj commented Jan 13, 2015

Sounds fair enough! Efficiency isn't too big of a deal when doing stuff in the microbe editor and regarding bumpy surfaces then we talked about not having to align the cytoplasm in hexes, I'd imagine that this would help!

@jjonj

This comment has been minimized.

Show comment
Hide comment
@jjonj

jjonj Jan 13, 2015

Contributor

tjwhale created a post about a proof of concept for cell deformation: http://thrivegame.forum-free.ca/t1508-cell-membrane#31501 that perhaps could be incorporated! I'm not really sufficiently experienced in the subject to judge for myself at this point.

Contributor

jjonj commented Jan 13, 2015

tjwhale created a post about a proof of concept for cell deformation: http://thrivegame.forum-free.ca/t1508-cell-membrane#31501 that perhaps could be incorporated! I'm not really sufficiently experienced in the subject to judge for myself at this point.

@Moopli

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli Jan 14, 2015

Contributor

Thing is, we don't need to finely tune the metaball surface -- we can convert the metaball funcion to an SDF, add some smooth noise, and the surface generated by marching-cubes will have much less regular bumpiness. Then, we can do a bunch of vertex post-processing, smoothing/roughening the surface further.

Right now, we absolutely don't need the surface produced by the metaballs to look perfectly-tuned. We just need it fully hooked-up and rendering in-game.

As for solutions that don't build the skin from a volumetric function (for example, the drawing-splines stuff), I have yet to see any solution that will give us a complete, smooth surface with the amount of customized shape we need.

tjwhale's idea is pretty much generating coherent noise over a sphere -- it looks nice with one control point (the center of the circle), but add more control points and you pretty much have to define a metaball function anyway to get a smooth "average surface" over which you apply the noise. In the end it's a suboptimally-efficient way to noise a mesh. We still have to get the mesh somehow.

Contributor

Moopli commented Jan 14, 2015

Thing is, we don't need to finely tune the metaball surface -- we can convert the metaball funcion to an SDF, add some smooth noise, and the surface generated by marching-cubes will have much less regular bumpiness. Then, we can do a bunch of vertex post-processing, smoothing/roughening the surface further.

Right now, we absolutely don't need the surface produced by the metaballs to look perfectly-tuned. We just need it fully hooked-up and rendering in-game.

As for solutions that don't build the skin from a volumetric function (for example, the drawing-splines stuff), I have yet to see any solution that will give us a complete, smooth surface with the amount of customized shape we need.

tjwhale's idea is pretty much generating coherent noise over a sphere -- it looks nice with one control point (the center of the circle), but add more control points and you pretty much have to define a metaball function anyway to get a smooth "average surface" over which you apply the noise. In the end it's a suboptimally-efficient way to noise a mesh. We still have to get the mesh somehow.

@Moopli

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli Jan 14, 2015

Contributor

Right after I wrote that comment I came up with an idea: Say you draw your microbe's skin in profile (ie, a closed, self-intersection-free curve that defines the intersection of the microbe surface with the plane which results in the largest enclosed area). Find the SDF of this curve, and you get a good starting measure of how fat your microbe should be on that part of the cross-section. Obviously, that has to be processed further to give us a depth, to remove the sharp edges and make it all nice and bulbous. This would just be different way to produce the volume that we run marching cubes on, of course, so all the post-processing mesh-stretching stuff can still be done.

Contributor

Moopli commented Jan 14, 2015

Right after I wrote that comment I came up with an idea: Say you draw your microbe's skin in profile (ie, a closed, self-intersection-free curve that defines the intersection of the microbe surface with the plane which results in the largest enclosed area). Find the SDF of this curve, and you get a good starting measure of how fat your microbe should be on that part of the cross-section. Obviously, that has to be processed further to give us a depth, to remove the sharp edges and make it all nice and bulbous. This would just be different way to produce the volume that we run marching cubes on, of course, so all the post-processing mesh-stretching stuff can still be done.

@patowen

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen Jan 14, 2015

Contributor

That might work. However, I still think that ideally, we could bypass marching cubes all together and start out with a mesh. It could be a simple, almost cylindrical mesh that we then subdivide and smooth.

Contributor

patowen commented Jan 14, 2015

That might work. However, I still think that ideally, we could bypass marching cubes all together and start out with a mesh. It could be a simple, almost cylindrical mesh that we then subdivide and smooth.

@Moopli

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli Jan 14, 2015

Contributor

Well, one easy way to speed it up would be to generate at much lower resolution, and then project the generated vertices to the implicit surface. We could get, probably, at least an order of magnitude reduction in mesh size that way, since the surface shouldn't need any areas of fidelity/curvature high enough to justify the current sampling resolution.

Contributor

Moopli commented Jan 14, 2015

Well, one easy way to speed it up would be to generate at much lower resolution, and then project the generated vertices to the implicit surface. We could get, probably, at least an order of magnitude reduction in mesh size that way, since the surface shouldn't need any areas of fidelity/curvature high enough to justify the current sampling resolution.

@TjWhale

This comment has been minimized.

Show comment
Hide comment
@TjWhale

TjWhale Jan 14, 2015

Hi guys, TJWhale here, I've updated my thread to show three examples with multiple control points. Hope you like it!

TjWhale commented Jan 14, 2015

Hi guys, TJWhale here, I've updated my thread to show three examples with multiple control points. Hope you like it!

@Moopli

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli Jan 19, 2015

Contributor

@patowen I've been thinking about bypassing marching cubes, and here's what I've come up with:

I think it would be difficult and annoying to generate a mesh by subdivision if we stick to a surface defined by hex-grid metaballs. Luckily, it should be possible if instead of metaballs we use some sort of cross-section spline thing like I described above.

Once we've generated a nice, blobby volume in SDF form, we can generate a starting mesh by taking a spherical mesh and projecting each vertex outwards from the center to the actual surface. In areas of sufficient roughness, we subdivide and project recursively. We generate an SDF because projection is very easy when using one -- you read the projection distance directly off the SDF, and calculate the gradient to get the direction.

I'm not sure if there's an easy, efficient way to calculate the SDF of an arbitrary solid -- if not, then we'd project points to the surface using some on-the-fly binary searching.

Contributor

Moopli commented Jan 19, 2015

@patowen I've been thinking about bypassing marching cubes, and here's what I've come up with:

I think it would be difficult and annoying to generate a mesh by subdivision if we stick to a surface defined by hex-grid metaballs. Luckily, it should be possible if instead of metaballs we use some sort of cross-section spline thing like I described above.

Once we've generated a nice, blobby volume in SDF form, we can generate a starting mesh by taking a spherical mesh and projecting each vertex outwards from the center to the actual surface. In areas of sufficient roughness, we subdivide and project recursively. We generate an SDF because projection is very easy when using one -- you read the projection distance directly off the SDF, and calculate the gradient to get the direction.

I'm not sure if there's an easy, efficient way to calculate the SDF of an arbitrary solid -- if not, then we'd project points to the surface using some on-the-fly binary searching.

@TjWhale

This comment has been minimized.

Show comment
Hide comment
@TjWhale

TjWhale Jan 19, 2015

Sounds a little like what I've been doing in my thread. Not sure if I'm on the right track at all. Have a look at the 3d stuff.

http://thrivegame.forum-free.ca/t1508-cell-membrane#31501

TjWhale commented Jan 19, 2015

Sounds a little like what I've been doing in my thread. Not sure if I'm on the right track at all. Have a look at the 3d stuff.

http://thrivegame.forum-free.ca/t1508-cell-membrane#31501

@Moopli

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli Jan 19, 2015

Contributor

I haven't had the time to go through your code @DrChewbacca, so I can't really judge (also the reason I haven't commented). How are you generating new surface points? So far it looks nice, but the important feature missing is the triangulation of the points. Depending on how you're generating new points, this might be easy or very hard.

Contributor

Moopli commented Jan 19, 2015

I haven't had the time to go through your code @DrChewbacca, so I can't really judge (also the reason I haven't commented). How are you generating new surface points? So far it looks nice, but the important feature missing is the triangulation of the points. Depending on how you're generating new points, this might be easy or very hard.

@TjWhale

This comment has been minimized.

Show comment
Hide comment
@TjWhale

TjWhale Jan 19, 2015

Not sure what "triangulation of points" means, sorry. What I've been doing is generating the net using polar coordinates with radius and angle(s).

The algorithm is

  1. Generate a net, evenly spaced by angle(s), at random radius not less than the distance from the origin to the furthest organelle.
  2. Smooth the net*
  3. If any point too close to an organelle (euclidean distance in space) then it is moved further away from the origin (it's radius is increased).
  4. Possibly shrink wrap a bit (move all points closer to the origin).
    goto 2

*the way the smoothing works is just via the heat equation but the best way to think of it is "each point tries to be the average distance from the origin of it's neighbours".

So for any point it knows it's radius (r) and it's neighbours radii (r_n for 1..n) and then calculates

change in r = 0.1* (sum (r_n,n) - n*r)

so if there are no organelles then the smoothing will make the net into a sphere but if there are any then (3) will mean there are lumps. But it will always be smooth because any local noise or spikes are smoothed out very quickly.

Hope this makes sense, I'll happily explain again if this is hard to understand.

TjWhale commented Jan 19, 2015

Not sure what "triangulation of points" means, sorry. What I've been doing is generating the net using polar coordinates with radius and angle(s).

The algorithm is

  1. Generate a net, evenly spaced by angle(s), at random radius not less than the distance from the origin to the furthest organelle.
  2. Smooth the net*
  3. If any point too close to an organelle (euclidean distance in space) then it is moved further away from the origin (it's radius is increased).
  4. Possibly shrink wrap a bit (move all points closer to the origin).
    goto 2

*the way the smoothing works is just via the heat equation but the best way to think of it is "each point tries to be the average distance from the origin of it's neighbours".

So for any point it knows it's radius (r) and it's neighbours radii (r_n for 1..n) and then calculates

change in r = 0.1* (sum (r_n,n) - n*r)

so if there are no organelles then the smoothing will make the net into a sphere but if there are any then (3) will mean there are lumps. But it will always be smooth because any local noise or spikes are smoothed out very quickly.

Hope this makes sense, I'll happily explain again if this is hard to understand.

@Moopli

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli Jan 19, 2015

Contributor

An example of the sort of triangulation I mean is the Delaunay Triangulation. We need to convert the set of points into a mesh which approximates the same surface that the points approximate, and one of the best was to do this is to make triangles out of any points that are close enough, while avoiding self-intersections and other non-manifold geometry. Thanks to these extra restrictions, there are a lot of edge cases you have to consider when making a mesh out of a scattering of points over a surface.

Hence what @patowen suggested above, and what I elaborated on, where we take a spherical mesh (a surface guaranteed to be manifold) and shift vertices in ways that we can guarantee will avoid self-intersection, and subdivide.

So basically, I think it will be hard (or at least annoying) to generate a mesh from what your code produces; so if you want to try making your point-smoothing system produce meshes, you should figure out how to put edges between your vertices right when you generate them, and thus essentially be writing an implementation of the subdivide/morph idea discussed above.

Contributor

Moopli commented Jan 19, 2015

An example of the sort of triangulation I mean is the Delaunay Triangulation. We need to convert the set of points into a mesh which approximates the same surface that the points approximate, and one of the best was to do this is to make triangles out of any points that are close enough, while avoiding self-intersections and other non-manifold geometry. Thanks to these extra restrictions, there are a lot of edge cases you have to consider when making a mesh out of a scattering of points over a surface.

Hence what @patowen suggested above, and what I elaborated on, where we take a spherical mesh (a surface guaranteed to be manifold) and shift vertices in ways that we can guarantee will avoid self-intersection, and subdivide.

So basically, I think it will be hard (or at least annoying) to generate a mesh from what your code produces; so if you want to try making your point-smoothing system produce meshes, you should figure out how to put edges between your vertices right when you generate them, and thus essentially be writing an implementation of the subdivide/morph idea discussed above.

@patowen

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen Jan 20, 2015

Contributor

We should also be careful to make sure the player has enough control over the shape and overall look of the microbe. One way to do this is to make sure that the mesh can tightly conform to hexes created by the player, but additional constraints would also be useful. Are we clear of our end goal, or does that need to be discussed in the forums?

Contributor

patowen commented Jan 20, 2015

We should also be careful to make sure the player has enough control over the shape and overall look of the microbe. One way to do this is to make sure that the mesh can tightly conform to hexes created by the player, but additional constraints would also be useful. Are we clear of our end goal, or does that need to be discussed in the forums?

@TjWhale

This comment has been minimized.

Show comment
Hide comment
@TjWhale

TjWhale Jan 20, 2015

How I have been doing it is that for every point it's angle(s) never change(s), only it's radial distance from the origin.

So any which are neighbours at the start are neighbours for all time and then can never overlap or cross. The manifold is diffeomorphic to a sphere at all times.

This does slightly reduce the number of shapes you can have but I think it makes things nice and simple.

"where we take a spherical mesh (a surface guaranteed to be manifold) and shift vertices in ways that we can guarantee will avoid self-intersection, and subdivide." - this is what I've been doing.

TjWhale commented Jan 20, 2015

How I have been doing it is that for every point it's angle(s) never change(s), only it's radial distance from the origin.

So any which are neighbours at the start are neighbours for all time and then can never overlap or cross. The manifold is diffeomorphic to a sphere at all times.

This does slightly reduce the number of shapes you can have but I think it makes things nice and simple.

"where we take a spherical mesh (a surface guaranteed to be manifold) and shift vertices in ways that we can guarantee will avoid self-intersection, and subdivide." - this is what I've been doing.

@Moopli

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli Jan 23, 2015

Contributor

@patowen All the people who need to be involved are here, no worries. What scheme do you have in mind for constraining the mesh to the player-created hexes?

Contributor

Moopli commented Jan 23, 2015

@patowen All the people who need to be involved are here, no worries. What scheme do you have in mind for constraining the mesh to the player-created hexes?

@patowen

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen Jan 24, 2015

Contributor

Sorry for the lack of response, as I am not entirely sure of my scheme, yet. My previous comment was me voicing my concern that the player will be forced to play as an indistinct blob if we are not careful. I will experiment when I have time, but it involves meddling in an area of 3D graphics that I currently lack experience in.

Contributor

patowen commented Jan 24, 2015

Sorry for the lack of response, as I am not entirely sure of my scheme, yet. My previous comment was me voicing my concern that the player will be forced to play as an indistinct blob if we are not careful. I will experiment when I have time, but it involves meddling in an area of 3D graphics that I currently lack experience in.

@Moopli

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli Jan 24, 2015

Contributor

@DrChewbacca

this is what I've been doing.

Not quite -- a mesh has not only the vertices but also the triangles connecting them. You have a vertex set which you subdivide and smooth, not a mesh.

@patowen I see what you mean -- a membrane defined by, say, NURBS, would be very smooth and boring unless we either add more control points or use some sort of trickery. Remember though: our goal for membrane rendering is to use a shader to make the membrane nearly transparent except when viewed close to tangentially, so the membrane looks something like what one would see in an optical microscope or TEM. We can probably avoid worrying almost entirely about the near and far surfaces, and just make sure they don't do anyhting too unreasonable.

Contributor

Moopli commented Jan 24, 2015

@DrChewbacca

this is what I've been doing.

Not quite -- a mesh has not only the vertices but also the triangles connecting them. You have a vertex set which you subdivide and smooth, not a mesh.

@patowen I see what you mean -- a membrane defined by, say, NURBS, would be very smooth and boring unless we either add more control points or use some sort of trickery. Remember though: our goal for membrane rendering is to use a shader to make the membrane nearly transparent except when viewed close to tangentially, so the membrane looks something like what one would see in an optical microscope or TEM. We can probably avoid worrying almost entirely about the near and far surfaces, and just make sure they don't do anyhting too unreasonable.

@patowen

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen Jan 24, 2015

Contributor

That's true. Giving the user control of the microbe's look in the third dimension, which the user will never see, isn't really necessary. I'm pretty sure the main problem I currently have with NURBS is that I'm not sure how easy that is to implement and how possible it will be to correctly smooth it out. A lot of this probably just comes from lack of experience.

Contributor

patowen commented Jan 24, 2015

That's true. Giving the user control of the microbe's look in the third dimension, which the user will never see, isn't really necessary. I'm pretty sure the main problem I currently have with NURBS is that I'm not sure how easy that is to implement and how possible it will be to correctly smooth it out. A lot of this probably just comes from lack of experience.

@Moopli

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli Jan 24, 2015

Contributor

NURBS aren't easy to mesh/render at all. You basically have to build a recursive subdivision surface to create more and more vertices that fit the NURBS curves, until the output mesh looks "good enough". This is why I've been trying to stick to a system that goes thorugh creating an implicit surface and then meshing that -- you can easily guarantee that it will be smooth and manifold, and you can use a bunch of fudge factors to make the implicit function cheap to calculate.

Of course, I'm likely just more in my comfort zone when working with implicit surfaces.

Contributor

Moopli commented Jan 24, 2015

NURBS aren't easy to mesh/render at all. You basically have to build a recursive subdivision surface to create more and more vertices that fit the NURBS curves, until the output mesh looks "good enough". This is why I've been trying to stick to a system that goes thorugh creating an implicit surface and then meshing that -- you can easily guarantee that it will be smooth and manifold, and you can use a bunch of fudge factors to make the implicit function cheap to calculate.

Of course, I'm likely just more in my comfort zone when working with implicit surfaces.

@patowen

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen Jan 24, 2015

Contributor

That's true. The problem I find with implicit functions is that we also have to decide which points to plug in and do something like marching cubes. If we want a fine mesh and we do it naively, we'll have a dense 3D grid of points, which will likely be too slow. I used marching cubes with the metaballs in my original implementation, and that lagged a bit when the mesh was being modified.

There's likely no one best way of doing this. Perhaps we should lightly consider the creature stage in case we want some similarities between the membrane and skin calculations. I highly doubt hexes will be used in anything but the 2D stages.

Contributor

patowen commented Jan 24, 2015

That's true. The problem I find with implicit functions is that we also have to decide which points to plug in and do something like marching cubes. If we want a fine mesh and we do it naively, we'll have a dense 3D grid of points, which will likely be too slow. I used marching cubes with the metaballs in my original implementation, and that lagged a bit when the mesh was being modified.

There's likely no one best way of doing this. Perhaps we should lightly consider the creature stage in case we want some similarities between the membrane and skin calculations. I highly doubt hexes will be used in anything but the 2D stages.

@Moopli

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli Jan 24, 2015

Contributor

Well, to put it simply, then we don't do it naively, and don't generate a fine mesh.

Given that we require the membrane to be simply-connected, then we can generate the mesh by projecting the vertices of a simpler mesh (say, a sphere centered on the origin) outwards, either along the gradient, or along straight lines away from the origin. Then we apply some simple subdivision criterion (for example, by inserting new vertices in the middle of long edges), and repeat the projection and subdivision on the new vertices a few times.

Contributor

Moopli commented Jan 24, 2015

Well, to put it simply, then we don't do it naively, and don't generate a fine mesh.

Given that we require the membrane to be simply-connected, then we can generate the mesh by projecting the vertices of a simpler mesh (say, a sphere centered on the origin) outwards, either along the gradient, or along straight lines away from the origin. Then we apply some simple subdivision criterion (for example, by inserting new vertices in the middle of long edges), and repeat the projection and subdivision on the new vertices a few times.

@Moopli

This comment has been minimized.

Show comment
Hide comment
@Moopli

Moopli Jan 24, 2015

Contributor

And now for a worked example:

Consider a membrane which the user controls using the method outlined above:
Rabies' Concept
Suppose the curve is kept bilaterally symmetric, and the user cannot make a curve that "doubles back on itself" from the point of view of the nucleus (which we can justify biologically somewhat, as a cytoskeleton has all microtubules anchored right by the nucleus, they don't bend much, and they're the main determinors of the large-scale shape of the cell -- yes, we ignore neurons, but that's okay as they don't swim freely). Then, to give us our third dimension, we rotate this curve around the axis of the cell.

This entire process is simple enough that we need not actually ever build a volume to then produce a mesh from -- we can just evaluate, in-place, the target position of any particular vertex:

interpolate(x,y,z) ->
    # where y is along axis of symmetry, x and z are interchangeable due to symmetry
    theta = atan(hypot(x,z), y)
    newdistance = control_curve.get(theta)
    scale = newdistance / hypot(x,y,z)
    x,y,z *= scale
    return x,y,z
Contributor

Moopli commented Jan 24, 2015

And now for a worked example:

Consider a membrane which the user controls using the method outlined above:
Rabies' Concept
Suppose the curve is kept bilaterally symmetric, and the user cannot make a curve that "doubles back on itself" from the point of view of the nucleus (which we can justify biologically somewhat, as a cytoskeleton has all microtubules anchored right by the nucleus, they don't bend much, and they're the main determinors of the large-scale shape of the cell -- yes, we ignore neurons, but that's okay as they don't swim freely). Then, to give us our third dimension, we rotate this curve around the axis of the cell.

This entire process is simple enough that we need not actually ever build a volume to then produce a mesh from -- we can just evaluate, in-place, the target position of any particular vertex:

interpolate(x,y,z) ->
    # where y is along axis of symmetry, x and z are interchangeable due to symmetry
    theta = atan(hypot(x,z), y)
    newdistance = control_curve.get(theta)
    scale = newdistance / hypot(x,y,z)
    x,y,z *= scale
    return x,y,z
@patowen

This comment has been minimized.

Show comment
Hide comment
@patowen

patowen Jan 24, 2015

Contributor

I like the idea of not building a volume and just building the mesh outright, and I do know how to rotate curves around an axis. Unfortunately, I do not think that rotating curves around an axis gives players the effect they would want, since ridges would be common. I also like the idea of editing the outline of the cell rather than having the membrane determined by the hexes. I'm not sure why I was against the idea earlier. Maybe I overestimated how good metaballs were.

I'll try to think of some other way of introducing the third dimension in a way that is neither NURBS nor revolving around an axis (which would also require symmetry). I doubt think such an algorithm will be trivial, but coming up with something good should be doable. It would probably start with something like NURBS, but smoother to begin with (with fudge factors).

Contributor

patowen commented Jan 24, 2015

I like the idea of not building a volume and just building the mesh outright, and I do know how to rotate curves around an axis. Unfortunately, I do not think that rotating curves around an axis gives players the effect they would want, since ridges would be common. I also like the idea of editing the outline of the cell rather than having the membrane determined by the hexes. I'm not sure why I was against the idea earlier. Maybe I overestimated how good metaballs were.

I'll try to think of some other way of introducing the third dimension in a way that is neither NURBS nor revolving around an axis (which would also require symmetry). I doubt think such an algorithm will be trivial, but coming up with something good should be doable. It would probably start with something like NURBS, but smoother to begin with (with fudge factors).

@TjWhale

This comment has been minimized.

Show comment
Hide comment
@TjWhale

TjWhale Jan 25, 2015

I'm not really sure that I'm helping. I had another go with filling in the triangles, results are here.

http://thrivegame.forum-free.ca/t1508-cell-membrane#31533

Feel free to ignore me if I'm way out of my depth and not understanding the problem properly. Thanks for your time.

TjWhale commented Jan 25, 2015

I'm not really sure that I'm helping. I had another go with filling in the triangles, results are here.

http://thrivegame.forum-free.ca/t1508-cell-membrane#31533

Feel free to ignore me if I'm way out of my depth and not understanding the problem properly. Thanks for your time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment