| |
In lugnet.cad.dat.parts, Jim DeVona wrote:
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
| |
In lugnet.cad.dat.parts, Joshua Delahunty wrote:
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
|
|
| |
| |
Since the proof-of-concept work for texture mapping took place “out in the
open” on Facebook, Steve is aware of what’s been done so far.
|
Actually, I’m not sure I’ve ever seen example source LDR/image files, or
even a definition of the syntax.
|
Me neither. Nothing on Facebook is “out in the open”, since it is a
walled garden.
|
By the definitions of that article, *LUGNET* is a walled garden.
<blank stare>
I have put up a step-by-step showing example source LDR/image files. I did it
on Facebook, because it took me almost no time to do. I’d either have had to
set up my own page with captions and HTML and whatnot, or used the arbitrary
walled-garden LUGNET syntax, or perhaps joined FLICKR (its own community) and
figured out those nuances (and I believe I have better control over
text/captions and ordering on Facebook, so the presentation proceeds in the
right order).
I joined Facebook because Todd and Suz were there, and it was how I could
communicate with them. I thought they were downright nuts at first, and had to
be dragged in kicking and screaming. When I did, however, at least 35 invites
flew my way from ALE’s I thought I barely knew (but they knew me).
Now when I post images from the proof-of-concept texture mapping syntax that I
developed -- in private because a) it’d been jump started and failed about 3
times previously because of design-by-committee and b) the fact that attitude
and preference often get in the way of progress and development -- I have 50
ALEs see it immediately, many of them TLG employees.
I also get to drop an f-bomb and have no one freak out, if I want to (not that I
would do so capriciously, but it’s darned nice to have the option).
I respect your opinion, Jim, but this is LUGNET member number 3 insisting that
he chose the right vehicle for the job at hand, without a doubt in his mind.
http://www.facebook.com/album.php?aid=2048041&id=1532162912&l=4199f78c01
-- joshuaD
|
|
| |
In lugnet.cad.dat.parts, Joshua Delahunty wrote:
This is really interesting work. Just curious, but have you considered how
you’d implement bump mapping as well? (Bump mapping would allow the “rough”
texture on slopes, for instance. I think that would be the only application for
it, but there are patterned slopes, so they would need both a texture and a bump
map.)
|
|
| |
In lugnet.cad.dat.parts, Andrew Westrate wrote:
> In lugnet.cad.dat.parts, Joshua Delahunty wrote:
> >
> > <http://www.facebook.com/album.php?aid=2048041&id=1532162912&l=4199f78c01>
>
>
> This is really interesting work. Just curious, but have you considered how
> you'd implement bump mapping as well? (Bump mapping would allow the "rough"
> texture on slopes, for instance. I think that would be the only application
> for it, but there are patterned slopes, so they would need both a texture and
> a bump map.)
If I'm not mistaken, two big pushes were made for texture mapping, in 2004 and
2007. Both failed because of too much committee, too little action. This after
previous attempts were made, of course, but looking at LUGNET, that's when the
big attempts were made to organize and get going.
We (a non-ALE software engineer buddy and I) have actually had texture mapping
working as a proof for one-and-a-half to two years! Before that was done, he
tried writing an application that took a bitmap (of arbitrary resolution) and
created triangles and quads from fields of color within it -- basically what a
part author does when he creates what I term "design by architecture" --
creating the design using the primitives of a mesh; which is how all part
patterns up to now have been done (albeit by hand). [side note that everyone we
showed it to HATED it -- the files bloated quite a bit, and the quality just
wasn't good enough to make it work]
The texture mapping proof that followed sat around for 6 months as I tried to
generate interest; interest that really didn't flower when the demo consisted
more of simply explaining how it could work, and how it should work.
It wasn't until I actually created the right sample texture, using gradients and
alpha channel (stuff that had always been possible, but explaining and showing
are two different things), and showed that working, that a major part author and
a major application writer got on board.
Change comes to LDRAW, but it happens very slowly. I worked with James, I worked
with Terry, I worked with Steve, and I worked with Chris. I have the plans to
go much, much further. When Turbo Pascal and EGA graphics were the norm, LDRAW
was impressive. Now that hardware transform and lighting [which is capability
ranked far beyond the needs of simple texture mapping] are nearly de rigeur, we
seem finally ready for texture mapping. It's a slow process.
I'm loathe to promise ANYTHING considering how long it's taken to get us this
far.
As the texture mapping proof sat in wait, I heard the same thing: time and
again: "MLCAD won't be able to do this; it doesn't use OpenGL, it doesn't use
graphics hardware. No one will adopt this without that." Indeed, that issue
exists.
I finally got over the hump [of convincing people that texture mapping was
"it"], and I said I wanted gloss maps, and I've been told it's not that useful,
that kind of hardware isn't available everywhere, it'll never work.
Well, we'll see. We reserved the tokens in the "language" for texture mapping
to define it, it really won't be that hard, it just takes the first person to
implement the shader language to make it happen.
My understanding of bump mapping is SLIGHTLY fuzzy (I'm not sure whether it fits
into the realm of multi-texturing, or fully in custom shaders), but I feel
FAIRLY confident enough to call that sort of invention an evolution of this
process, rather than a revolution.
Will bump mapping come to LDRAW (or at least LCAD?)?
Well, let's just say I've been paying an awful lot of attention (and drooling)
over the animation found here:
http://technic.lego.com/en-us/Products/default.aspx#8048
(click the yellow (Animation) link, wait for the zoom in on the motor). I think
that animation represents the rubber hitting the road :wink: <pause for
groaning>, and that we'll be able to do that with LCAD tools some day, without a
doubt.
Would that it not take another 15 years :)
-- joshuaD
P.S. put more succinctly, as people see the value in texture mapping, and ask
how they ever did without it, much more will be possible. Getting to where we
are now was an application of existing tools, it wasn't rocket science.
Incrementally improving it can and will happen. And I've obviously had both
gloss maps and bump maps on my mind as we've gone.
|
|
| |
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?
|
|
| |
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?
But that's different from parts authors being able to use bump mapping in a part
file. Or specific colors actually being implemented as bumps/textures -- so
'rubber black' actually looks distinct from 'black'.
|
|
| |
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, 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?
As it happens, the stud logos in LDView are just regular textures.
--Travis
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
> 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?
>
> As it happens, the stud logos in LDView are just regular textures.
Wow, what a let down! I'm totally disappointed (with my apparently failing
memory, not with you or LDView. Well, ok, maybe I'm just a teeny bit less
impressed with LDView right now, but I'll get over it. :)
Have fun,
Don
|
|
| |
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
|
|
|
