diana_coman: | mp_en_viaje: re the easy question, meanwhile I got at least some idea as to what might be involved/the general steps; and as a result, I have this niggling thought that it's possible that either I don't quite get what you have in mind or you don't quite get what cs/cal3d can actually do (and esp what they can't /don't do); so I'd rather discuss this to make sure we are in sync ... | [11:21] |
ossabot: | Logged on 2020-03-04 13:10:26 mp_en_viaje: is this hard ? | [11:21] |
diana_coman: | ... before proceeding further | [11:21] |
diana_coman: | to start with: cs and cal3d are able to do essentially *only* the rendering of what I'd call pre-rasterised "models" ; specifically for cs this means wireframe representations of a static model ; for cal3d this means skeletal/morphanimations with an emphasis on the fact that any "skeleton" is more part of cal3d's format for animation than of anything else really (and certainly 0 to do with "it's part of a character/shape/model" or ... | [11:26] |
diana_coman: | ... anything as straightforward as that; if anything, the "skeleton" is at most part of the *animation* aka of interpolating between 2 static poses, pretty much. | [11:26] |
diana_coman: | getting back to the concrete task set there, the "display" part is actually the one that is the hard part by far, from what I understand so far. | [11:27] |
ossabot: | Logged on 2020-03-04 13:00:32 mp_en_viaje: take a fractal to be your texture ; take an arbitrary graph, to be your skeleton ; take some paramatric manner (such as, say, fibonnaci might inspire) to do the dampening. produce the object and diplsy it. | [11:27] |
diana_coman: | if I understand correctly what you have in mind, you are simply thinking of some parametric description of the model, which arguably is "relatively cheap", sure; the thing is that CS/Cal3d can do exactly 0 with such parametric description; to "produce and display" means essentially doing meshing and tesselation (basically some sort of sampling for obtaining the vertices as a discrete representation and then defining the triangles that ... | [11:36] |
diana_coman: | ... approximate the desired surface); for both steps, there are various constraints wrt to what makes for a "good mesh" - and good there means that rendering systems ala cs/cal3d will not choke on it, not that "it looks great" or anything of the sort. | [11:36] |
diana_coman: | on the bright side, the real options there seem relatively limited in that despite a huge pile of papers and algorithms, there are only a few core things that seem to work in practice; on the less bright side, it's precisely this "meshing" that is considered/acknowledge as "the hardest part". | [11:37] |
diana_coman: | to summarise: in order to "display" anything (so even before considering how the result of one or another approach re "wrapping" might *look*), I have to pick & implement some sort of meshing + tesselation; only *after that*, we can get to the "shits and giggles" with whatever else. | [11:41] |
diana_coman: | I guess I should also explicitly add that the looks of whatever ends up displayed will depend significantly on the meshing+tesselation (even to such extent as to wonder how much the other part really matters in the end because the perceived result is after all ~looks) | [11:49] |
diana_coman: | waves | [14:04] |
diana_coman: | for added lulz, in cs/libs/cstools there seems to be an attempted implementation of some triangulation via ear clipping algorithm: it's full of commented out stuff, it has parts with comments "to finish implementing" and it's not mentioned at all in the manual because indeed, it looks incomplete at best. | [14:06] |
diana_coman: | given that cs has at least primitives such as cones, I wonder if it's worth to attempt perhaps making a cone-based model to see how that looks like + behaves on animation; after all, there's also supposedly the "constructive geometry" approach of making stuff out of basic shapes (and at least the primitives are meshed+triangulated in the CS code - if some are basically ...hardcoded o.O ) | [14:09] |
diana_coman: | meshed+tesselated* technically speaking; I end up calling it triangulated because a. cs uses triangles for the tesselation b. I got delauney triangulation stuck in my head apparently. | [14:15] |
diana_coman: | on further reflection, it seems to me that the meshing+tesselation is pretty much the only real option; because building it out of existing primitives doesn't really deliver much benefit - the little that might be won on no-need-to-mesh-or-tesselate is lost anyway on trouble at joints/connecting points for the most obvious bit (likely not even the only one). | [16:20] |
Comments feed: RSS 2.0