Parametric Surfaces

[zz85]

This almost feels like I'm on some crazy geometry spree.

Parametric surfaces ftw, credits to @prideout for his brilliant article http://prideout.net/blog/?p=44

http://jsbin.com/ivekup/3/edit#preview

UVs to be done another day... :)

[mrdoob]

Haha, this is getting crazy indeed :)

[mrdoob]

So SphereGeometry could then reuse/extend this SurfaceGeometry?
And while we're at it... could TorusKnotGeomery reuse/extend TubeGeometry?

[zz85]

well, both are possible - we can even go to more extremes
eg. PlaneGeometry extends SurfaceGeometry (actually I think maybe ParametricGeometry sounds better?)
Torus / TorusKnot extends TubeGeometry, soon we might even have TubeGeometry extends ParametricGeometry (#905)
although i would have thought that you hold the unix like philosophy of keeping things simple but efficient :)

Ok, now see http://jsbin.com/urahod/4/edit

Now notice these points that might occur after switching to using a parametric geometry for sphere

1. The ParametricGeometry uses triangles instead of quads - maybe this is a good thing with regards to Non-planar quad faces #1664
2. Not too sure if we will can create normals for the faces ( https://github.com/zz85/three.js/blob/bff6fd3047838c17ba0bc54bc8e9a83a875990a9/src/extras/geometries/SphereGeometry.js#L79 ) - otherwise the parametric function might require custom normals (like how the parametric Curve supports .getTangent)

As far as TorusKnotGeomery goes, I could try to do that, although it might require a bit of work to keep the old API compatible..

[zz85]

okay, now compare TorusKnotGeomery with TorusKnotGeomery2 :)

http://jsbin.com/isecib/3/edit

[mrdoob]

okay, now compare TorusKnotGeomery with TorusKnotGeomery2 :)

http://jsbin.com/isecib/3/edit

Nice! :D

although i would have thought that you hold the unix like philosophy of keeping things simple but efficient :)

Yep, but I'm also worried about filesize. And there is a lot of dupe code in these geometries...

[zz85]

reduced filesize - perhaps :) efficiency - perhaps more objects are created, but might or might not have any hit.. okay, i gotta reinstall git sometime soon...

[zz85]

The UVs gonna be an interesting problem for parametric surfaces. Not sure if we gonna have one way of doing it, or have multiple UV mapping strategies.

So I wrote a little UV helper to help with understanding the current UV system and debugging.

Live link for the common THREE geometries http://jsbin.com/ujejuq/edit#javascript,live

Hopefully this would also help in debugging UV problems such as #1396 #1645 #1288

Most of it are boring grids others than these (and perhaps exported UV unwarps)

[zz85]

UVs is another deep rabbit hole again... perhaps we could also do something like this http://www.briankadar.com/blog/2009/03/dynamic-uv-texture-mapping/

UtilsUV.applyPlaneUV( plane, rect );
UtilsUV.applyCubeUV( cube, rect, Cube.FRONT );

which is also relating to the topic in #1396

[mrdoob]

Yup, isn't that the same as this?

THREE.GeometryUtils.UVMapSphere( geometry, matrix );
THREE.GeometryUtils.UVMapCylinder( geometry, matrix );
THREE.GeometryUtils.UVMapCube( geometry, matrix );
THREE.GeometryUtils.UVMapFlat( geometry, matrix );

However, that would work work for simple objects such as cubes, spheres and so on. But Torus Knots?

[zz85]

yes, similar... :) except that we haven't implemented it yet right?

what's the matrix arguments for?

[zz85]

TorusKnots could use Cylinder mapping I think. As long we are not dealing with complex models yet.. I was reading about LSCM while on the topic... http://www.blender.org/download/sandbox/lscm-basics/

[mrdoob]

what's the matrix arguments for?

For rotating the mapping. For example, if you're doing Flat mapping you can use the matrix for controlling where to project from.

TorusKnots could use Cylinder mapping I think.

I don't think that would look good, TorusKnot needs it's own custom mapping, no?

[zz85]

hmm.. i realized we might be talking about different UV approaches. What you seem to be saying for those util classes to project UV (un)mapping from the real world coordinates of the geometry's vertex/faces.

I was rather thinking about the old way our UVs were done, if you look at the current UVs of TorusKnot , they are similar to Cylinder (scroll down in http://jsbin.com/ujejuq/edit#javascript,live)

Parametric Surfaces by definition on wikipedia is defined by a parametric equation with two parameters. In that way, the 2 parameters, let's say u and v, can be easily UV mapped for any parametric equation with some form of factory or builder design pattern.

Since @gyuque and @alteredq both worked on the UVs of ExtrudeGeometry, wonder if they have anything to comment about?

[zz85]

oh was @WestLangley also mentioning on that the THREE.IcosahedronGeometry UV Map should be planar or something?

[mrdoob]

I was rather thinking about the old way our UVs were done, if you look at the current UVs of TorusKnot , they are similar to Cylinder (scroll down in http://jsbin.com/ujejuq/edit#javascript,live)

Parametric Surfaces by definition on wikipedia is defined by a parametric equation with two parameters. In that way, the 2 parameters, let's say u and v, can be easily UV mapped for any parametric equation with some form of factory or builder design pattern.

Ah! I'm starting to understand now... :)

[WestLangley]

@zz85

oh was @WestLangley also mentioning on that the THREE.IcosahedronGeometry UV Map should be planar or something?

Yes, he did say that, but he might not be correct...

In your (awesome) plots above, why does vertex b of face 39 have so many edges?

[zz85]

@WestLangley hmm... not sure if that's a bug or feature, I supposed that UVs should wrap around to the right of faces 20, 76 -> 37, 77, if UV repeats are enabled correctly.

[zz85]

@mrdoob so now the "replacement" ParametricGeoemtries are now under examples/js/ParametricGeoemtries.js. not sure if its a good idea to refactor all geometries to ParametricGeoemtry - specialized geometry classes may have their advantages but the idea can be continued to be play with...

[mrdoob]

Yup. Sounds good to me!

However, instead of this:

THREE.PlaneGeometry = function(width, depth, segmentsWidth, segmentsDepth) {

    function plane(u, v) {

        var x = u * width;
        var y = 0;
        var z = v * depth;

        return new THREE.Vector3(x, y, z);
    }

    THREE.ParametricGeometry.call(this, plane, segmentsWidth, segmentsDepth);

};
THREE.PlaneGeometry.prototype = new THREE.Geometry();
THREE.PlaneGeometry.prototype.constructor = THREE.PlaneGeometry;

I think I would just do this:

THREE.PlaneGeometry = function(width, depth, segmentsWidth, segmentsDepth) {

    function plane(u, v) {

        var x = u * width;
        var y = 0;
        var z = v * depth;

        return new THREE.Vector3(x, y, z);
    }

    return new THREE.ParametricGeometry(plane, segmentsWidth, segmentsDepth);

};

[zz85]

would this mean that the pattern would change? eg.

var plane = THREE.PlaneGeometry(100, 100, 10, 10);
var mesh = new THREE.Mesh(plane, material);

vs

var plane = new THREE.PlaneGeometry(100, 100, 10, 10);
var mesh = new THREE.Mesh(plane, material);

[mrdoob]

Oh true. Yeah, it's good as it is then :)

[zz85]

Morphing parametric geometries test - http://jsdo.it/zz85/rVta

Thanks to the idea @mrdoob mentioned here

[mrdoob]

Nice! :D

[zz85]

I guess we can close this issue soon, if there's isn't any more problems or requests for this feature :)