#eulora Logs for 09 Mar 2020



March 9th, 2020 by Diana Coman
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

Leave a Reply