| |
In lugnet.cad.dat.parts, Don Heyse wrote:
> In lugnet.cad.dat.parts, Joshua Delahunty wrote:
> >
> > Will bump mapping come to LDRAW (or at least LCAD?)?
>
> I was under the impression that LDView already uses bump mapping for
> the stud logos. Is that wrong?
Texture maps let us wrap images to polygons. This is great for painted images
on surfaces, such as mini-figure torsos or the sides of walls.
Bump maps describe how each point (texel) in the texture reacts to light, by
describing a virtual "height" to that point. Then when light sources change, the
texture "reacts" more convincingly. This is good for things like orange peel,
rubber, or the textured surfaces we (used to) get with sloping bricks.
There are even more advanced techniques than bump mapping, all of which simulate
an actual texture that can be seen "on edge", reacts to light, and so on, from
normal mapping all the way up to displacement mapping. The cooler the effect,
the more powerful the hardware you need to show it, but the more convincing the
images.
Gloss maps, which I advocate coming into the picture eventually, indicate which
points on a texture reflect light in a specular fashion. This will be good for
gold, silver, and copper paints on patterns that use those paints. The parts of
the pattern that are gold or silver or copper will be "shiny", while the rest
won't. Then, when a part is displayed in a changing environment (like spinning
in LDView, though there are more useful examples too, IMO), the light will shine
off the shiny parts as the object moves in front of light sources.
As for the TEXMAP syntax, we "reserved" space for indicating a gloss map, and
the same can be done for other types of maps as well. Right now, one could do:
0 !TEXMAP START PLANAR 0 0 0 1 1 1 2 2 2 <texture-filename> GLOSSMAP
<glossmap-filename>
* currently GLOSSMAP doesn't actually do anything in any supporting application,
but is planned for future expansion *
It would be very simple to add additional keywords to the !TEXMAP START command
for bump maps, normal maps, even displacement maps.
Implementing these things wouldn't even be all THAT difficult. The points that
are actually at issue are these:
* How widespread is your target audience's "decent" hardware capability?
This is becoming less and less of an issue. Even "entry level" graphics cards
now sport Hardware T&L (transform and lighting) quite capable of the mid-level
(bump-mapping, normal-mapping) features I'm talking about at a really decent
speed. And that's with video games at 30 frames per second and millions of
polygons. LDRAW just isn't that kind of application, ESPECIALLY the number of
objects that need to be textured.
* What condition and quality is your input data in?
I really think this is where we'll need some ramp up. Who has the technical
know-how to get us professional quality textures (and I mean that in the generic
sense -- image, bump, gloss, normals, etc., the whole package) that will produce
top results in the viewers? To me, this is the real challenge. We can get
viewers that show these features with a little bit of R&D (it comes down to
reading up on a technique online and then tweaking the code to fit your input
data; once that's done, it's more work but not insurmountable to make the new
features work with older features in existing renderers).
The hard part is getting all the proper input data prepared so it looks right
and works to everyone's satisfaction.
Check out the date on this proof I did:
http://www.facebook.com/photo.php?pid=30693110&l=94b60efd85&id=1532162912
(I did the back of the torso]
http://www.facebook.com/photo.php?pid=30691970&l=f1243ed558&id=1532162912
That's a 2010 torso and legs, back in November, 2009. It was possible simply
using my scanner and the TEXMAP technology. But does it look pro? To be sure,
to have the figure ready-to-roll 40 minutes after opening the set is a
mind-blower, but long-term, that imagery needs to be redone in
Illustrator->Photoshop to have a really sharp and pro look.
----
This Pirate guy was done in the same way:
http://www.facebook.com/photo.php?pid=30698924&l=ec37e856ea&id=1532162912
(he needs gloss maps, so the gold medallion on his chest, and the buckles on the
bag on his back, will shine properly)
The expertise to get them to the level of attention I gave Indy here:
http://www.facebook.com/album.php?aid=2040316&id=1532162912&l=c7b84a178a
is what will be the challenge (and I'm talking consistency and dedication over
quality -- I'm not perfect at this stuff by any means).
-- joshuaD
LUGNET member #3
P.S. Don, I've had someone suggest that I "encourage" support of this syntax in
LDGlite. Are you up for it? Already working on it?
|
|
| |
In lugnet.cad.dat.parts, Joshua Delahunty wrote:
>
> P.S. Don, I've had someone suggest that I "encourage" support of this
> syntax in LDGlite. Are you up for it? Already working on it?
I've been tossing this around for a while, and while I'm not sure who'd
really use it in ldglite considering LDView is so much better suited for
modern OpenGL use, it still seems like it'd be fun to experiment with.
So, are there any example files available with the modified .dats and the
.png texture files? Something like this one might be a good start because
then I could compare the texture and the fallback .dat vector rendering.
http://www.facebook.com/photo.php?pid=30701291&id=1532162912&l=c7b84a178a
Don
|
|
| |
In lugnet.cad.dat.parts, Don Heyse wrote:
> So, are there any example files available with the modified .dats and the
> .png texture files? Something like this one might be a good start because
> then I could compare the texture and the fallback .dat vector rendering.
>
> http://www.facebook.com/photo.php?pid=30701291&id=1532162912&l=c7b84a178a
You can find some sample files here:
http://www.halibut.com/~tcobbs/ldraw/private/texmapped.zip
Note that some of the files may have BFC issues. Look at 973pa9.dat for a file
that has fallback geometry. As a side note, rebel_tile.dat (and the part it
points to) have bad texture coordinates, so the texture is mirrored.
--Travis
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
> In lugnet.cad.dat.parts, Don Heyse wrote:
> > So, are there any example files available with the modified .dats and the
> > .png texture files? Something like this one might be a good start because
> > then I could compare the texture and the fallback .dat vector rendering.
> >
> > http://www.facebook.com/photo.php?pid=30701291&id=1532162912&l=c7b84a178a
>
> You can find some sample files here:
>
> http://www.halibut.com/~tcobbs/ldraw/private/texmapped.zip
Thanks, that was quick.
By the way, I'm still not sure whether it's really worth it to attempt
this in ldglite, or if it'd be more worthwhile to try something that
might actually end up being useful, like say a minifig modeler (or maybe
an lsynth GUI) built around LDVlib.dll. Can it process new geometry
fast enough to form the nucleus of a general LDraw editor, with parts
moving around in real time?
Don
|
|
| |
In lugnet.cad.dat.parts, Don Heyse wrote:
> In lugnet.cad.dat.parts, Travis Cobbs wrote:
> > In lugnet.cad.dat.parts, Don Heyse wrote:
> > > So, are there any example files available with the modified .dats and the
> > > .png texture files? Something like this one might be a good start because
> > > then I could compare the texture and the fallback .dat vector rendering.
> > >
> > > http://www.facebook.com/photo.php?pid=30701291&id=1532162912&l=c7b84a178a
> >
> > You can find some sample files here:
> >
> > http://www.halibut.com/~tcobbs/ldraw/private/texmapped.zip
>
> Thanks, that was quick.
>
> By the way, I'm still not sure whether it's really worth it to attempt
> this in ldglite, or if it'd be more worthwhile to try something that
> might actually end up being useful, like say a minifig modeler (or maybe
> an lsynth GUI) built around LDVlib.dll. Can it process new geometry
> fast enough to form the nucleus of a general LDraw editor, with parts
> moving around in real time?
LDVLib doesn't allow you to edit models at all. You point it at an existing
file and tell it to load. Having said that, if you wanted to do some (most?) of
the work, it could probably be made to be usable for a minifig modeler, since
high-performance isn't really an issue with a minifig.
I'd have to tweak the graphics engine side of LDView to have an "edit" mode, and
you'd have to create the C API inside LDVLib to handle editing. You're not the
first person to request editing in LDVLib, but I don't really see myself doing
all the work.
--Travis
|
|
|
