From 0ea5fc66924303d1bf73ba283a383e2aadee02f2 Mon Sep 17 00:00:00 2001 From: neodarz Date: Sat, 11 Aug 2018 20:21:34 +0200 Subject: Initial commit --- pipermail/nel/2001-December/000830.html | 132 ++++++++++++++++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 pipermail/nel/2001-December/000830.html (limited to 'pipermail/nel/2001-December/000830.html') diff --git a/pipermail/nel/2001-December/000830.html b/pipermail/nel/2001-December/000830.html new file mode 100644 index 00000000..ad05065b --- /dev/null +++ b/pipermail/nel/2001-December/000830.html @@ -0,0 +1,132 @@ + + + + [Nel] Re: Nel digest, Vol 1 #207 - 4 msgs + + + + + + + + + +

[Nel] Re: Nel digest, Vol 1 #207 - 4 msgs +

+ Paul Siegel + + psiegel@geneticanomalies.com +
+ Wed, 19 Dec 2001 11:05:16 -0500 +

+
+ +
Cyril to the rescue again!  (Or do you prefer Hulud?  And if so, will you
+tell me what it means?)  You know, I've gotten slower responses from
+"support" that I pay for.  My thanks again.
+
+> You can build patches with an heightfield. It a fast way to generate
+> a simple lansdcape. Simply raise the tangeants vertices with the joined
+> vertices of a bezier patch : you have a heightfield !
+
+Hmm, I'm not sure I parse this, but it intrigues me.  Unfortunately, my
+knowledge of height fields is even less than that of bezier patches, the
+latter of which I've only learned as I researched writing this plugin.  What
+do you mean by "the joined vertices"?  Are these the four outer corner
+vertices of a bezier patch?  And what happens to the interiors?
+
+> The BindEdges info are required to properly link patches together at
+> runtime. You have to filled them for internal zone linking. zone_welder
+> will fill them of inter-zone link. Hear come some explications on how to
+fill the
+> CBindInfo.
+
+Thanks, the info was very helpful.  I've coppied it over into a monospaced
+text file, and it all makes sense.  I'm guessing now that the program I've
+been working with is much more simplistic than what you've had to deal with
+(though I guess it doesn't take much to be more simplistic than max!)
+
+The plugin includes the following code with which I can deal:
+
+typedef struct {
+ float x, y, z;
+} SP_Vector;
+
+typedef struct {
+ long v1, v2, v3;
+} SP_Triangle;
+
+typedef struct {
+ SP_Vector ctrlPoints[4][4];
+
+ long  numPoints, numTriangles;
+ SP_Vector *points, *normals;
+ SP_Triangle *triangles;
+} SP_Patch;
+
+void SPExportPatch(SP_Patch *patch)
+{
+ /* This function is called for each patch in a layer. */
+ /* Every patch is described as both a set of control points (for a cubic
+Bezier */
+ /* patch) and as a set of triangles - use whichever you need. */
+ }
+
+Unfortunately there appears to be no information whatsoever on the
+interconnectivity of the patches.  Therefore, I can either add some complex
+ruitines to mathematically figure out which patches are adjacent to each
+other and therefore how to bind them, or move along to another piece of
+software with hopefully better export data.  I'd really hate to do the
+former as I've actually got the thing exporting zone files (they just have
+no bind info, and would probably look like hell if I tried to use them).
+The latter though seems rather intimidating, especially with my limited
+knowledge of three dimensional geometry.
+
+Well, before I make that decision I want to be sure I understand all the
+data I need to create these patches.  I've got the vertices, tangents,
+interiors, and now the BindInfo structs.  There is also an array of
+BaseVertices in the CPatchInfo object that I don't think I understand.
+Besides that the rest of the data appears to concern coloration and tiles,
+which I'm not going to worry about yet (recall that's phase 2).  Is it valid
+though to set OrderS and OrderT to 0, and therefore only supply a single
+color for the entire patch?  Will the patch render, or will I see nothing
+until I complete phase 2 (painting the patches)?
+
+Paul
+
+
+
+
+
+ + + + + +
+

+ -- cgit v1.2.1