Supported altanative UV mapper on ExtrudeGeometry

[gyuque]

Implementation of Issues #1396
and may have something to do with #1683?

[mrdoob]

@zz85 I let you decide on this one ^^

[zz85]

thanks, i'll take a look into this. :)

[zz85]

testing this with texture = THREE.ImageUtils.loadTexture( 'textures/ash_uvgrid01.jpg' );

the CylinderUVGenerator seems to work pretty well. I'm not too sure about how's WorldUVGenerator supposed to work though...

CylinderUVGenerator

WorldUVGenerator

@alteredq do you remember how UVs were on ExtrudeGeometry?

merged to https://github.com/zz85/three.js/compare/uvs first.

[alteredq]

@zz85 Like this:

[zz85]

@alteredq your screenshot is how the UVs are currently which is the same for my previous screenshot.

It seems like either there's a bug to this kind of UV wrapping (many UV values are way above 1 while usually they are a range from 0..1?) or I don't understand what's going on here (the WorldUVGenerator).

[alteredq]

Well, that's the screenshot from the lib version at the time I merged that example (somebody else created it), whatever that means ;)

[zz85]

i'm looking at lots of interesting history on ExtrudeGeometry back to last year that I never knew existed :P

[mrdoob]

Is that good or bad? :P

[zz85]

at least there are people playing around with the code :)

i think i'll shall leave THREE.ExtrudeGeometry.WorldUVGenerator as it is right now until someone could give a better suggestion.

(sidenote: maybe i shouldn't be rebasing commits - github doesn't close this pull request automatically after merging now)

[mrdoob]

Yep. It's always better to merge
You keep the credit of the original author too :S

[alteredq]

What does "rebase" actually do?

I always use just fetch + merge, not even pull. I find it better to have separate steps, less chances to mess up something, also it's easier to deal with different branches from other repos in this way, at least in my client.

[zz85]

for example there are 2 branch with changes simultaneously
mrdoob -> A - B - C - D
alteredq -> E - F - G - H

if alteredq merges mrdoob, result might be something like
A ~ B ~ C ~ D
~ E ~ F ~ G ~ H

if alteredq rebases mrdoob, alteredq will take mrdoob changes, and replay alteredq's changes after mrdoob.
result would be
A - B - C - D - E' - F' - G' - H'

some like rebases because the commit history looks "cleaner". some people prefer a workflow for a dev branch to rebase the master, and a master to merge the dev branch for example. its also probably useful in a central git workflow (rather than distributed like github)

the drawbacks is that rebase modifies the history and its hashes. this is bad when you have pushed changes onto github and now you have to force push your rebased history. so have to be careful using rebase, if history have been already pushed to some where else.

anyways, looks like i'll will just use merge for the three.js now, sorry about the hiccup.

[alteredq]

Thanks for the explanation. This rebasing just feels so alien to me ;)

I'm already completely used to understand everything through this:

https://github.com/mrdoob/three.js/network

[mrdoob]

It's alien to me too :)
Closing this as it's been, somehow, merged already.

[arcanis]

It seems a bit late to point this out, but CylinderUVGenerator seem to have been lost in the merge 😄 (unless it's been removed at some point?)