(2018-01-13, 18:14)Roland Melkert Wrote:(2018-01-12, 23:00)Joshua Delahunty Wrote: Again, how does LDCad work currently? I'll ask Leo to mirror that work, and if the only two working examples are out of spec, at least they will be consistent.I've checked the sourcecode as it has been along time since I touched that part of the code, and it seems I'm using p3 at the same level as p1. But revisiting this now makes me want to change that (I'm about to release 1.6b anyway) to follow the spec and just invert the texcoord distance instead.
Current source of interest:
Code:TLDCylindricalTextureInfo::TLDCylindricalTextureInfo(TGL2DTexture *tex, const TGLVector3d &p1, const TGLVector3d &p2, const TGLVector3d &p3, const double angle) :
inherited(tex),
topCen(p1), botCen(p2), nor(p1-p2), restDir(p3-p1),
angle(deg2Rad(angle)), angleIs360(angle>=360.0 || angle<=-360.0) {
nor.normalize(len);
restDir.normalize();
};
void TLDCylindricalTextureInfo::calcUV(TGLVector3f **pnts, const int pntCnt, TGLVector2f *uv) {
//Alles via vec3d tbv rounding errors
TGLVector3d baseDir(false), curDir(false), pnt(false);
double baseAngle(0.0), curAngle;
for (int i=0; i<pntCnt; i++)
{
pnt.init(*pnts[i]);
TGLVector2f &tc=uv[i];
pnt.calcDirectionTo(botCen, nor, curDir);
curDir.inverse(); //moet van midden naar buiten net als restDir
curAngle=nor.calcSignedAngleBetween(curDir, i==0 ? restDir : baseDir);
if (i==0)
{
baseDir=curDir;
baseAngle=curAngle;
}
else
curAngle+=baseAngle;
tc.u=0.5+curAngle/angle;
tc.v=distanceToPlane(pnt, nor, topCen, nor)/len; //afst tot top
}
};
edit: A change isn't a big deal imho as officially the cyl/sph implementations in LDCad are still 'experimental'
I attempted to test CYLINDRICAL with LDCad last night, and either got no image (P3 even with P1) or a scrambled one (P3 even with P2). It was very strange.
In other news, my buddy changed Foundry last night to render textures correctly on transparent geometry, something that none of the platforms currently does right (including Foundry, as the reference platform). LeoCAD is close, he's using a shader to get the desired effect.
(The issue is, nearly every renderer will render the texture transparently when applied to transparent geometry, when the alpha of the texture and the alpha of geometry need to combine, with opaque alpha on the texture overriding any alpha of the underlying part. Both GL_DECAL and GL_REPLACE give the wrong results). I presumed we'd HAVE to go to a shader solution (something I don't really mind because it was always presumed to be needed for proper GLOSSMAP support), but Foundry is apparently doing a double render manuever to get the desired results.