Texture Mapping extension


Texture Mapping extension
#1
This is in reference to the LSC post

Do to the potential to reuse patterns at differing scales, I'd like to see the mapped images be in a vector based format. Thoughts?
Reply
Re: Texture Mapping extension
#2
I can see how it would be useful, but as a software author, I would prefer we didn't go down that road. In order for it to be useful, we'd probably want to use a standard vector format, and most likely that means SVG. Unfortunately, supporting SVG textures requires tools to incorporate some 3rd-party SVG library. Realistically, this would be the case for any standard vector file format; they're just too complicated to expect an LDraw program to directly parse them. (Using the LDraw format itself as the format for the vector "textures" would seem to defeat the purpose, since that wouldn't make part creation any easier.) From my point of view, that's yet another library that I have to get working in LDView, and I already have enough that it's quite difficult to get LDView to build on a clean machine. Adding one more just complicates things further. Also, it takes a lot longer to load (and then render) an SVG than to load a PNG.

In order to get the performance gains that textures bring, the vector texture would then need to be converted to an image by the rendering program, and that image would then be used as a texture map. And while it's true that the program could generate the image at a resolution that is based on the size at which the image is projected, I don't think this buys us much over simply making the PNG texture big enough to be useful in the largest part using the pattern.

I do feel that it would be perfectly reasonable to include vector versions of the textures in the parts library, and make it optional for rendering programs to use them. However, I feel that any such vector "texture" should be required to also include a PNG version that is simply a rendering of the SVG at an appropriate resolution. This would make it so that if someone created a part using a texture, and someone came back later and needed the texture to be bigger, they could simply re-render the vector graphic into a higher-resolution PNG file, and both the old and the new file would then work fine.
Reply
Re: Texture Mapping extension - Additional questions
#3
- How can we seperate between colours from LDConfig.cfg (e.g. 80 [Metallic Silver]) and direct colours (0x2RRGGBB) if we have only a image (SVG/PNG/JPEG/BMP/GIF..) as colour reference for the pattern?

- How can we get the material information of a specific colour from the image? For example, metallic silver is some kind of reflective.
Reply
Re: Texture Mapping extension - Additional questions
#4
I'm guessing because the texture is still used by a '4' or '3' line it will use that lines colour for base properties (incl it's colour for alpha blending). And when you need a pastern with multiple properties you have to divide it into multiple quads etc using multiple textures.
Reply
Re: Texture Mapping extension - Additional questions
#23
Roland Melkert Wrote:I'm guessing because the texture is still used by a '4' or '3' line it will use that lines colour for base properties (incl it's colour for alpha blending).

That is exactly how this works, and the proof of use of gradients and proper alpha blending were what was necessary to bring Travis onboard two years ago.

See the AT-AT dish (in green instead of grey so it really shows) and the "TEST/TEST/Philo was here!" dish at https://plus.google.com/photos/116975088...paign=link

Roland Melkert Wrote:And when you need a pastern with multiple properties you have to divide it into multiple quads etc using multiple textures.
While no one has yet had a need or use for multitexturing yet, this was the intended approach. As Travis mentioned elsewhere, each line as spec'd is to take an optional GLOSSMAP parameter, so each texture is defined to allow for it's own per-texel specularity value for making "shiny" colors actually reflect light appropriately.
Reply
Re: Texture Mapping extension - Additional questions
#6
You don't, and Joshua Delahunty (the one who initiated this process) has a proposed solution to the problem, but I didn't include his solution in my proposal. His solution is a separate gray-scale "glossmap" that determines the shininess of each pixel in the texture. Note also that while the textures will likely use RGB values from LDConfig.ldr, they will not be using LDraw color codes directly.

I removed references to gloss maps in the proposal for a few reasons. First of all, I haven't implemented support for it, and without a proof of concept implementation, I'm leery of proposing it for ratification. Secondly, Joshua's proposed syntax wouldn't have worked well with texture filenames that include spaces. It's legitimate to simply disallow spaces in texture filenames, but now that we allow spaces in model filenames (although not part filenames), I don't think that's the right approach. While it's true that the main motivation for the textures was parts, support for them could be added to modelers to allow arbitrary stickers.
Reply
Re: Texture Mapping extension
#5
I'll bow to your technical expertise on this.

The thing that concerns me and the reason I brought this up is that I really don't like the "fuzzy" lines of scanned patterns. If I want to make a model virtually, I expect the lines of the patterns to be nice and clean. While this doesn't necessarily need to be addressed in the spec, it definitely needs to be addressed in the policies for the Official Library.
Reply
Re: Texture Mapping extension
#7
I think it would be extremely important to capture each texture's source vector art in the part tracker and library. In addition to allowing the creation of higher-resolution textures in the future, it would also greatly facilitate editing existing patterns.

Allen
Reply
Re: Texture Mapping extension
#8
I agree that this would be very useful. Having said that, some textures won't have any vector artwork associated with them at all. For example, the jungle wall in the samples probably doesn't have any associated vector graphics. And while it could certainly use cleanup, it seems good enough as-is to be used in a "Needs Work" part. I don't think it would be a good idea to require that all textures have vector-based source artwork.
Reply
Re: Texture Mapping extension
#24
Travis Cobbs Wrote:I agree that this would be very useful. Having said that, some textures won't have any vector artwork associated with them at all. For example, the jungle wall in the samples probably doesn't have any associated vector graphics. And while it could certainly use cleanup, it seems good enough as-is to be used in a "Needs Work" part. I don't think it would be a good idea to require that all textures have vector-based source artwork.

The jungle wall just doesn't have artwork YET. ;-) Someone just has to sit down and trace it out, to give the best possible source material. But we did find that a quick scan and some background removal gave EXCELLENT "needs work" results in a very short time frame, and the quality was at or exceeding that of design-by-archiecture approaches in most cases. I recall having great fun finding a Space Police set on the shelves a couple months (November, prior to official January launch) prior to official release, and that night I had the entire figure: head, torso, legs decorated and in LDRAW ready to render. It was of course not up to the highest quality standards, but it was instant gratification and certainly up to released parts standards.

The jungle wall was an example of how a scan looks as opposed to a prepared vector-to-bitmap texture map from the initial examples pool, but the plan was ALWAYS to try to get it vectorized, to get everything vectorized. I redid upper part #5 (the original blue suit-and-tie) with vector art because even those simple shapes look much more true-to-life when vectorized-then-output-as-bitmap than the DbA version.

EDIT: fixed timeline
Reply
Re: Texture Mapping extension
#9
Isn't it a bit overkill to use texture's when there is vector data available?

Because unless it's a curved surface the vector data could translate into core LDraw format which in the long run produces higher quality because it won't go 'fuzzy' at closeups.
Reply
Re: Texture Mapping extension
#10
I agree on some level. However, the increasing complexity of patterns and printed parts necessitates this. It is far easier to redraw a high quality reproduction of a pattern in an image editor than to model it up with quads and triangles. I'd rather have a high quality drawn pattern that is used with texture mapping than nothing.
Reply
Re: Texture Mapping extension
#11
There was a big thread on patterns where I started on a program to convert SVG files into LDraw DAT files. However, SVG is a very complex file format, and I never got the program to the point where it could read arbitrary SVG files (and probably never will). I looked for an SVG library, but while they can be found to rasterize an SVG (convert from vector graphics to pixel graphics), I was unable to find one that would produce a set of non-overlapping triangles, as is needed for LDraw files.

The point, though, is that people were going to town creating SVG files that represented the patterns, but had no good way to get that information into the official library. Allowing their source SVG files to be in the library, while having pre-rendered PNG versions of the same files for use in programs like LDView, would, in my opinion, be very helpful.
Reply
Re: Texture Mapping extension
#12
Orion Pobursky Wrote:This is in reference to the LSC post

I would also like to discuss that post, though on a bit of a different tangent (Travis Cobbs suggested this was the right place to have some input on the subject).

BACKGROUND
Back in 2009, I worked with a friend who has a history of professional CAD/CAM development. He created a parser for the LDRAW format, using only the precise LDRAW specs as published on the site. He threw a quick-and-dirty GUI front end on it, and we named it "Foundry," the first step in what was to be (and still may be) a world-class part editor that would work with LDRAW compatible parts (there was some serious discussion of creating a higher-level curve-based or geometric-solids based language, and using the .DAT format as the tesselated output of "compiling" that language).

We then worked with Travis Cobbs to create the !OBI extension to LDRAW (which has yet to be submitted to the LSC). That extension allows for the "shading" of stud sides and tube hollows so that parts look as they did in Old Building Instructions (or Original Building Instructions, take your pick). Directives could be placed into code so that a compliant viewer can turn on or off the casting of defined surfaces to black to create this effect. We created a fairly feature-rich directive language, including START..END blocks, and single-line definition NEXT blocks. The effect would "dive into" sub-files as needed, and we had a method for setting and clearing macro values, so that the effect could be conditional inside a sub-file as defined "outside" that sub-file before the sub-file is "called" as if it were a sub-routine.

Foundry received the first OBI treatment, and then I patched in to LDView sources a fairly rich attempt to replicate that success. I had some issues identifying and conditionally disabling the feature with transparent parts* with his sources, so in the end Travis re-wrote the support from scratch and made it comform fully to that spec.

DESIGN BY ARCHITECTURE
Later, I wrote my first two design parts, the Exxon and trucker torsos. I found the "design by architecture" approach to be extrememely slow-going and error prone, and the fact that any design created could not be increased in resolution without a full re-design convinced me that it was time to make something happen with LDRAW texture mapping.

Our first attempt was to write an application that took a bitmap and tesselated it into triangles matching the image. Despite best efforts, and some interesting success, the numbers of triangles seemed prohibitive (source files would grow larger than bitmaps holding texture map textures would be, and they would ALWAYS load into the graphics pipeline, no shutting them off), plus we were still stuck without the ability to do gradients, which more and more decorated parts were featuring. We eventually abandoned this approach.


!TEXMAP DEVELOPMENT
So we developed the !TEXMAP syntax. I wrote the syntax, and my friend coded it into Foundry. We took an approach that would fit the existing LDRAW syntax, be more understandable to the typical layman than UV coordinate definitions, and felt we were off and running. Our first approach was to simply scan the image, slap it on a part, and call it a day. It was nearly INSTANTANEOUS designs on parts.

I asked Travis about running this work in front of the LSC, and also asked if he would add this feature to LDView as yet another unreleased standard. As I recall, it was proof that gradients did exactly what you'd expect that got him working to put the feature into LDView. On the former issue, though, he was reticent. He felt that non-support by MLCAD would be a huge blocker. In fact, nearly every one to a person asked me, upon seeing the results, "when can we get that in MLCAD?!"

The next step we took was to make sure that the FALLBACK syntax was designed and integrated, so that all existing work would continue to live on, and MLCAD compatible files could continue to be developed by those who did not want to upgrade.

I wrote texmap.txt, and furnished that to my friend. He turned it into texmap.doc, added the diagram of how planar mapping works, and added the end section on the Foundry Implementation (so Travis could base his approach on that of Foundry's).

So I had the overwhelming opinion of "that's tremendously cool, but it will never pass with most of the LDRAW population using MLCAD". Additionally I had another LDRAW author strongly advise me NOT to seek LSC approval, because it always resulted in delays. Much better to create something powerful and have people just use it. It was at this point that I dropped the idea of making !TEXMAP into an LSC standard, and set about changing people's minds one at a time...


A LIVING, DEVELOPED STANDARD
I've spent the next two years explaining how it works:
http://www.facebook.com/media/set/?set=a...4199f78c01

and expanding further and further the proof that it's worth the switch from MLCAD
http://www.facebook.com/media/set/?set=a...e2f35c7d88
(this was just the latest, I have a lot more)

Basically, this has been a de facto standard, living and in use, for the past two years. It has lived through many many "what if" and "how do we" scenarios to arrive at the syntax and workflow that were developed in that time.

so when Roland opines "you mean we can't change anything it's all or nothing?"

I have to say that
a) *I* did not submit this standard for consideration by the LSC, and
b) the standard has been developed and is operational, with two years of effort behind it

To take a standard that someone else developed, and then insist that the LSC should ratify that standard, but with certain features removed or modified because they don't "sound right" is, in the nicest terms possible, unfair and improper (and I don't mean this personally, Roland, I have great respect for your work, AND your view on software patents).


SUMMARY
On this topic, my position now is the same as it has been since the standard was written: it's out there to use. It's not official LDRAW syntax, and I have no desire to make it so. Support it if you like, or don't, but be aware that there are incompatibilities with official syntax (file names require quotes if you use spaces in them, for instance).

There are two viewers that support the syntax as designed now. Both fall just short of full compliance with the standard:

- LDView doesn't support quotation marks around the pngfile parameter and based on what he told me, GLOSSMAP would be supported as a texture file name if someone tried

- Neither actually supports GLOSSMAP operations (Travis didn't implement this at all, we were working on implementing lights in Foundry when we got bogged down with the weight of Yet Another Extension), and I'm pretty sure LDView doesn't treat it as a reserved word (see above)

- Neither supports CYLINDRICAL or SPHERICAL mapping (my friend told me it was a trivial addition, when the requirement would arise, for Foundry). LDView only treats CYLINDRICAL as a reserved word, not SPHERICAL (as I understand it)

I'd be most pleased to see expanded support of the standard. Yesterday, I ran into a need for CYLINDRICAL (else I'd probably have to match up two separate PLANAR mappings onto a curved surface -- NOT FUN), and my artist friend who has been working on textures for me has repeatedly asked for GLOSSMAP for all the shiny paints that appear on the minifigure series torsos now (see second link above for image of Kimono Girl, which SHOULD have shiny gold paint). He and I have also discussed the still-theoretical BUMPMAP support so we can do rubber in a pitted way like TLG does in their animations. CYLINDRICAL and GLOSSMAP are probably not very far off in the Foundry implementation, to be sure.

-- joshua


* a feature later found to be un-official, TLG *will* shade such parts. Oh, well.

EDIT: added footnote
Reply
Re: Texture Mapping extension
#13
hi Joshua Welcome to the board.

Judging from your reference to my stand on software patents (I'm against them) I think you understand my main concern.

Travis post made me think the whole texture standard is to be handled has Proprietary although I wouldn't mind that as separate entity (unofficial meta), but I do think anything part of the official LDraw standard shouldn't be hampert in such a way. Because the LSC won't be allowed to adjust it in any way like it does the core stuff as part of the LDraw evolution.

Judging from you post above I think we best add this meta as an unofficial extension (only information on ldraw.org)
Reply
Re: Texture Mapping extension
#14
Roland Melkert Wrote:Travis post made me think the whole texture standard is to be handled has Proprietary although I wouldn't mind that as separate entity (unofficial meta), but I do think anything part of the official LDraw standard shouldn't be hampert in such a way. Because the LSC won't be allowed to adjust it in any way like it does the core stuff as part of LDraw

A spec beyond the control of the LSC is exactly the reason why we decided to disallow POV-Ray code in the Official Library
Reply
Re: Texture Mapping extension
#15
The whole point of having a texture meta is so official LDraw parts can be created using it.

LDraw is a terrible language for making illustrations. Rather than spending huge amounts of time perfecting printed parts using LDraw geometry, people could make high-quality textures in minutes/hours. People who are good at part authoring could focus on real challenges instead. People who stink at part authoring (like me) could meaningfully contribute.

That's not going to happen if there's no agreed-upon standard to do so. That would be sad.

Allen
Reply
Re: Texture Mapping extension
#18
Allen Smith Wrote:The whole point of having a texture meta is so official LDraw parts can be created using it.

LDraw is a terrible language for making illustrations. Rather than spending huge amounts of time perfecting printed parts using LDraw geometry, people could make high-quality textures in minutes/hours. People who are good at part authoring could focus on real challenges instead. People who stink at part authoring (like me) could meaningfully contribute.

That's not going to happen if there's no agreed-upon standard to do so. That would be sad.

Allen

All the very solid reasons I've spent two years using and proving the technology.

It was one of the principles who first helped create the LDRAW committees who convinced me not to seek ratification, however. Innovation rarely occurs in a bureaucracy.

When I worked with James (and then Terry, and Steve), the goal was to invent means to get our work done, not have rules and roadblocks and limitations on our work. This is why I decided (and told Travis over a year ago) that I didn't want the LSC's involvement.

I've been discussing the situation with my co-author. We didn't intend for the work to be placed into public view in this manner, but that's just something we're having to deal with...
Reply
Re: Texture Mapping extension
#19
Joshua Delahunty Wrote:When I worked with James (and then Terry, and Steve), the goal was to invent means to get our work done, not have rules and roadblocks and limitations on our work. This is why I decided (and told Travis over a year ago) that I didn't want the LSC's involvement.

I'd like to point out here that I totally misinterpreted the email he sent me over a year ago where he meant that he didn't want the LSC's involvement. Re-reading it after he re-forwarded it to me, I can see in retrospect what he meant, but I didn't understand it at the time. (I know that seems strange, but the context was a response to an email I sent him which was totally unrelated to textures.)

Having said that, I've always felt as Allen does, which is that the point of the meta is so that textures can be used in official parts, and that can't happen without LSC ratification.
Reply
Re: Texture Mapping extension
#16
Unless I'm misunderstanding again, Joshua hasn't said that LDraw.org cannot add to this texture mapping standard in the future. He's saying that he does not want any sub-set of the standard he documented to be approved, and he doesn't want any changes to be made in the portion already documented. Furthermore, he expects to add new features in the future (that may be approved or not by the LSC).

I'm not saying that even these restrictions are necessarily acceptable to the LSC, just that things aren't quite as bad as it seems to be portrayed.
Reply
Re: Texture Mapping extension
#17
I'm fine with us adopting the spec but once we do so it should be considered an LSC controlled fork of the original spec. Joshua can do whatever he wants to with the original but our version won't necessarily reflect his changes.
Reply
Re: Texture Mapping extension
#20
I agree, adapting the current into a LSC controlled fork seems a reasonable compromise.

Although I can't help feeling a bit railroaded, although I fully understand it's not on purpose.
Reply
Re: Texture Mapping extension
#21
Orion Pobursky Wrote:I'm fine with us adopting the spec but once we do so it should be considered an LSC controlled fork of the original spec. Joshua can do whatever he wants to with the original but our version won't necessarily reflect his changes.

Awfully kind of you, allowing me to do what I want with my own spec. :-) Tongue

[Please note the double smiley: this comment was made to make light of the situation, I thought the phrasing here was humorous]

EDIT: added extra note about intent of the message.
Reply
Re: Texture Mapping extension
#22
In light of recent gnashing of teeth regarding the ownership of the proposed spec, I think we should create our own spec from scratch. This will prevent the inevitable fight that would ensue if we were to co-opt someone else's work without their express permission.
Reply
Re: Texture Mapping extension
#27
Orion Pobursky Wrote:In light of recent gnashing of teeth regarding the ownership of the proposed spec, I think we should create our own spec from scratch. This will prevent the inevitable fight that would ensue if we were to co-opt someone else's work without their express permission.

Agree with you. Adopting the propsed specs will leave both parties unsatisfied. The developers 'cos inevitable there will be made changes sooner or later, we 'cos we don't have the freedom to go in every direction and will always feel barred. The waste of time and efforts done by the developers is be a pity, but it's better to make a painful break than draw out the agony.

w.
LEGO ergo sum
Reply
Re: Texture Mapping extension
#25
Orion Pobursky Wrote:This is in reference to the LSC post

Do to the potential to reuse patterns at differing scales, I'd like to see the mapped images be in a vector based format. Thoughts?

Once the vector art is set-up (I've used Adobe Illustrator), it's been really simple to output higher-resolution versions of the same image when better fidelity has been needed (Save for Web and Devices...). I went FAR overboard on some of the early tests, using 1024x1024 texture maps for parts that were only a couple inches across.

I haven't tried a single 1Kx1K (or even 2Kx2K for the super fancy graphic carded enthusiast) for, say, the top view of a ramp-and-pit-plate, so that may not be enough. I imagine dividing such a part into quadrants (or more) for texture mapping.

what to do with a 32x48 baseplate of that style? Might need even more.

It will be an interesting experiment, once I get around to it.
Reply
Re: Texture Mapping extension
#26
I don't think it should be part of the official spec at all. I'm happy to see a texture mapped part library out there, and I'd be happy to see it linked to from the official parts library, and I'd probably download it. But I think that the parts library would be diminished by adapting a limited subset of the format, and I think that the library would be at risk adopting an external format.

The problem with adapting or adopting it officially is that, for editors and viewers that don't support the metas, the parts would reduce to their blank version. Which is far from ideal. Better, IMO, to keep the official library to those parts that work on any LDraw compatible editor/viewer, but allow people to go outside for the texture mapped parts.

Tim
Reply
Re: Texture Mapping extension
#28
That's not true. The spec very specifically has support for fallback geometry so that non-texture-supporting applications would display that instead. Any existing part that was updated to have a texture would continue to display exactly the same in applications not supporting textures. New parts modeled with textures would have whatever level of fallback geometry was considered appropriate. In the short run, this fallback geometry would likely be fairly detailed. In the long run (years down the road, once almost all LDraw apps support textures), this fallback geometry might be very rudimentary.
Reply
Re: Texture Mapping extension
#29
I was being a little extreme, but you would have to design the tile twice to fall back OK. Which may not be super difficult depending on how crude the fallback was.

Having the part external of the main library would allow the designer not to worry about making a crude fallback part (or to make a really, really crude one). Having them internal would require some balance of quality of fallback.

EDIT: Having given it a little more thought you could use very low-res versions of the texture to automatically make a fallback part so I take back that issue.

Tim
Reply
Re: Texture Mapping extension
#30
Tim Gould Wrote:I don't think it should be part of the official spec at all. I'm happy to see a texture mapped part library out there, and I'd be happy to see it linked to from the official parts library, and I'd probably download it. But I think that the parts library would be diminished by adapting a limited subset of the format, and I think that the library would be at risk adopting an external format.

The problem with adapting or adopting it officially is that, for editors and viewers that don't support the metas, the parts would reduce to their blank version. Which is far from ideal. Better, IMO, to keep the official library to those parts that work on any LDraw compatible editor/viewer, but allow people to go outside for the texture mapped parts.

Tim

This problem could be fixed if MLCAD had a software texture mapping renderer added. It IS possible. Smile
Reply
Re: Texture Mapping extension
#31
Orion Pobursky Wrote:This is in reference to the LSC post

I've added images of the texture-mapped minifigure series 4 lawn gnome (#1) to a google+ album (images for #2 kimono girl -- sans decor on her hair, we'll need CYLINDRICAL support for that -- and #3 Musketeer were already up)

https://plus.google.com/photos/116975088...6826227105

-- joshua
Reply
Re: Texture Mapping extension
#32
This looks nice, but I must admit I'm at a lost on how to proceed with the whole texture meta thing.
Reply
Re: Texture Mapping extension
#33
Roland Melkert Wrote:This looks nice, but I must admit I'm at a lost on how to proceed with the whole texture meta thing.

Travis removed three parts of the standard because they aren't implemented in code yet, and he felt that keeping things simpler would be less confusing.

However, the parts shown here need GLOSSMAP so the shiny paints will "look right", and CYLINDRICAL so that the Kimono Girl's head will properly wrap the texture that needs to be built for it. The Foundry author is looking into creating sample code for CYLINDRICAL (as he did for the original PLANAR support). We will need to add lightsources and multi-texturing with a shader to Foundry to provide sample code for GLOSSMAP (after CYLINDRICAL is implemented).

So I had an issue with cutting features out of the standard when they're really not optional, long term.

As should be obvious from the way the meta was so carefully built, it was designed to work in the LDRAW system, including backwards compatibility, and that was our goal when we started.

In the past two years since, several interested parties, including LDRAW committee members, advised me that the meta might "do better" if it remained external. Unfortunately, that change of plans was not communicated to Travis in the clearest manner, and he proceeded with his presentation of the specification -- also unfortunately not well communicated *back* to me a priori, so Travis and I could get on the same page.

I don't have an issue with ratification, despite the advice that ratification by the LSC has often killed innovation in the past, but rest assurred that we plan to continue our work and to expand the specification as necessary, whether it's fully "external" or not.

The best approach, in my humble opinion, would be to ratify the entire spec as it stands (if ratification happens), since we are planning to implement the "excised" portions in the coming weeks or months, and there would be a pretty quick follow-up vote otherwise.

-- joshua
Reply
Re: Texture Mapping extension
#34
Joshua Delahunty Wrote:I don't have an issue with ratification, despite the advice that ratification by the LSC has often killed innovation in the past, but rest assurred that we plan to continue our work and to expand the specification as necessary, whether it's fully "external" or not.

Can I have an example of this? In fact, I can't think of any currently ratified spec that wasn't internally developed by the LSC or one of it's members.
Reply
Re: Texture Mapping extension
#35
Orion Pobursky Wrote:
Joshua Delahunty Wrote:I don't have an issue with ratification, despite the advice that ratification by the LSC has often killed innovation in the past, but rest assurred that we plan to continue our work and to expand the specification as necessary, whether it's fully "external" or not.

Can I have an example of this? In fact, I can't think of any currently ratified spec that wasn't internally developed by the LSC or one of it's members.

The advice I received was that, once ratified, most tech never really continued to be innovated forward in a major fashion.

I wasn't provided examples, however.

It's quite possible that, once a technology is ratified, it's reached near enough to its potential that it no longer has much room for additional features, and there is a measure of coincidence involved.
Reply
Re: Texture Mapping extension
#36
I think both BFC and MPD pre-date the LSC, but were ratified after the LSC came into existence.
Reply
Re: Texture Mapping extension
#37
Joshua Delahunty Wrote:…but rest assurred that we plan to continue our work and to expand the specification as necessary, whether it's fully "external" or not.

I have been meaning to look at implementing this syntax for several years, but when Travis brought it up again, I was finally stimulated to get started. While writing a parser for this texture syntax, several questions have arisen. I would appreciate it if you could answer them:

1. You have mentioned your intention to extend this syntax. Where are such extensions going to happen? How are they going to be backwards-compatible with a parser which does not implement them?

2. Suppose I have an image file named
Code:
"Evil" grin.png
What does the TEXMAP START line look like to reference that file?

3. What is the result of the following code snippets?
(Please ignore any actual numbers; they are for demonstration purposes only.)
(Please treat each snippet as if it were contained in a separate file)

Code:
0 // Snippet 1
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
3 4 0 0 0 80 0 0 40 -40 0

Code:
0 // Snippet 2
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 // comment
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0

Code:
0 // Snippet 3
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP END
3 4 0 0 0 80 0 0 40 -40 0
0 !TEXMAP END

Code:
0 // Snippet 4
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image2.png
0 !TEXMAP END
3 4 0 0 0 80 0 0 40 -40 0

Code:
0 // Snippet 5
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !: 0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
0 !: 4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !: 0 !TEXMAP END
0 !: 3 4 0 0 0 80 0 0 40 -40 0
0 !TEXMAP END

Code:
0 // Snippet 6
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !: 0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
0 !: 4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !: 0 !: 0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
0 !: 0 !: 4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !: 0 !: 0 !TEXMAP END
0 !: 0 !TEXMAP END
3 4 0 0 0 80 0 0 40 -40 0
0 !TEXMAP END

Code:
0 // Snippet 7
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 STEP
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP END

Code:
0 // Snippet 8
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
3 4 0 0 0 80 0 0 40 -40 0
0 STEP
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP END
Reply
Re: Texture Mapping extension
#38
Joshua Delahunty Wrote:…but rest assurred that we plan to continue our work and to expand the specification as necessary, whether it's fully "external" or not.

Allen Smith Wrote:I have been meaning to look at implementing this syntax for several years, but when Travis brought it up again, I was finally stimulated to get started. While writing a parser for this texture syntax, several questions have arisen. I would appreciate it if you could answer them:

1. You have mentioned your intention to extend this syntax. Where are such extensions going to happen? How are they going to be backwards-compatible with a parser which does not implement them?

We intend to implement CYLINDRICAL and GLOSSMAP fairly soon, SPHERICAL may or may not follow (mostly for completeness, but CYLINDRICAL was in some folk's eyes not needed until very recently).

There was talk for some time of a BUMPMAP extension, so that rubber textures could be done.

For the former, they are in the spec now, a program that didn't want to support them should implement the keywords in the parser, and issue an error (which I believe LDView does currently, though I may be wrong) unless and until it does support them.

For the latter, BUMPMAP may be at the same level as TEXMAP, so it would technically be a comment to any parser that didn't understand the keyword.


Allen Smith Wrote:2. Suppose I have an image file named
Code:
"Evil" grin.png

What does the TEXMAP START line look like to reference that file?
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 "\"Evil\" grin.png"


Allen Smith Wrote:3. What is the result of the following code snippets?
(Please ignore any actual numbers; they are for demonstration purposes only.)
(Please treat each snippet as if it were contained in a separate file)

Code:
0 // Snippet 1
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
3 4 0 0 0 80 0 0 40 -40 0

First let me say that the "texture stack" was partially left over from our OBI work, where it was important to keep track of whether OBI was on or off repeatedly. In some ways, it "wasn't my area." But I'll proceed based on my understanding of the intended operation. I'd say that nesting these guys would just lead to confusion in most cases, and -- as you mentioned -- it's mostly about how these might work if you left something "open" as you went into a sub-file.

In this case, the quad would have image2.png applied, and the tri would have image.png applied (following the spec).


Allen Smith Wrote:
Code:
0 // Snippet 2
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 // comment
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0

The comment is ignored, the quad gets image.png applied.

Allen Smith Wrote:
Code:
0 // Snippet 3
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP END
3 4 0 0 0 80 0 0 40 -40 0
0 !TEXMAP END

quad -> image2.png
tri -> image.png

Allen Smith Wrote:
Code:
0 // Snippet 4
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image2.png
0 !TEXMAP END
3 4 0 0 0 80 0 0 40 -40 0

quad -> image.png
tri -> image2.png

I'm going to guess that this MAY not work in the current impl of LDView.


Allen Smith Wrote:
Code:
0 // Snippet 5
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !: 0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 !: 0 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !: 0 !TEXMAP END
0 !: 3 4 0 0 0 80 0 0 40 -40 0
0 !TEXMAP END

According to the spec, this should result in a syntax error on the '4 !: ...' line.

Only 0 !: is an acceptable meta.

Allen Smith Wrote:
Code:
0 // Snippet 6
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !: 0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 !: 0 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !: 0 !: 0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 !: 0 !: 0 4 4 0 -100 0 80 -100 0 80 -180 0 0 -180 0
0 !: 0 !: 0 !TEXMAP END
0 !: 0 !TEXMAP END
3 4 0 0 0 80 0 0 40 -40 0
0 !TEXMAP END

You'd have a syntax error here as well. Further, the nesting of :! is not supported in the spec. The point of :! is to allow legal geometry to be parsed by a TEXMAP-compliant parser while that same geometry is ignored by older parsers.

something like
Code:
0 !TEXMAP START PLANAR  1 1 1  2 2 2  3 3 3  image.png
0 !TEXMAP_GEOMETRY 4 16 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP_GEOMETRY 3 16 0 0 0 80 0 0  80 -80 0
0 !TEXMAP FALLBACK
4 16  0 0 0  80 0 0  80 -80 0  0 -80 0 0 80 0
3 16  0 0 0  80 0 0  80 -80 0  0 -80 0
0 !TEXMAP END

was determined to be too unwieldy, so we reduced those lines to a constant (and thin) vertical border to make them more readable:

Code:
0 !TEXMAP START PLANAR  1 1 1  2 2 2  3 3 3  image.png
0 !: 4 16 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !: 3 16 0 0 0 80 0 0  80 -80 0
0 !TEXMAP FALLBACK
4 16  0 0 0  80 0 0  80 -80 0  0 -80 0 0 80 0
3 16  0 0 0  80 0 0  80 -80 0  0 -80 0
0 !TEXMAP END

To a non-TEXMAP application, the above would still apply the existing design (made of quads and tris and so on).

Allen Smith Wrote:
Code:
0 // Snippet 7
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 STEP
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP END

Good question. My guess, by spec, would be to act as if the 0 STEP was before the 0 !TEXMAP, and the quad would have image.png applied. The intent of the current spec is that START..END and NEXT always apply to non-comment lines. I'm not sure what the corner cases are for other valid comment-commands or metas. Travis might be able to answer that one better than I.

-- joshua
Reply
Re: Texture Mapping extension
#39
My apologies; Snippets 5 and 6 contained typographical errors with the leading "4". I have edited my post to correct them. Could you please also edit your responses?

Also note the addition of Snippet 8. I forgot this one the first time around.

Thanks,
Allen
Reply
Re: Texture Mapping extension
#73
I realized in reading over some of this thread today what some of our misunderstandings have been...

7 and 8, the way we set up the spec (only in part files, TEXMAP is meant to bind decorations to parts instead of "design-by-architecture" means) shouldn't be an issue. The idea was to have a design encapsulated within a part definition, and the texture stack support was only for the very rare case that an s part need to have nested textures upon them, while the part using the s portion also was in the middle of a texture definition. So STEP shouldn't happen in the middle of a TEXMAP definition.

- joshua
Reply
Re: Texture Mapping extension
#53
Joshua Delahunty Wrote:
Orion Pobursky Wrote:This is in reference to the LSC post

I've added images of the texture-mapped minifigure series 4 lawn gnome (#1) to a google+ album (images for #2 kimono girl -- sans decor on her hair, we'll need CYLINDRICAL support for that -- and #3 Musketeer were already up)

https://plus.google.com/photos/116975088...6826227105

... and here is almost certainly the most complicated design I've seen done yet (the graphics work continues to be done by an artist friend of mine) -- either with design-by-architecture or texture mapping: the viking from Minifigures series 4. I output all the textures as 512x512 this time for better fidelity (we actually had to scan at a higher resolution this time to get all the finer detail in his torso -- 300 dpi wasn't enough for this one). Admittedly, 256x512 is probably overkill for each leg, but outputting new images at half that size would be trivially quick for me to do. It all comes down to a balance of quality versus storage space.

Viking image

-- joshua
Reply
Re: Texture Mapping extension
#54
It looks impressive, although I'd like to see the figure rendered in LDView with lights turned on. Or even better, rendered with POV.
Reply
Re: Texture Mapping extension
#55
Daniel Görner Wrote:It looks impressive, although I'd like to see the figure rendered in LDView with lights turned on. Or even better, rendered with POV.

That was renderered in LDView (if that wasn't clear)

I'll try to get out a shot with lights.

One of our members who has left the fold had written code to convert/port the texmap syntax over so it could be generated in POV nearly effortlessly. I fear that work has walked with him, however.

-- joshua
Reply
Re: Texture Mapping extension
#60
Does anyone know what the units for the 'a' and 'b' parameters are? Radians? Degrees? Something else entirely?
Reply
Re: Texture Mapping extension
#61
Some more questions...

1. Are there any meta-commands which may not appear in the geometry sections? Is, for example, nesting !TEXMAP blocks in the same file supported?

0 !TEXMAP START PLANAR ...
0 !: 1 16 0 0 0 1 0 0 0 1 0 0 0 1 somepart.dat
0 !TEXMAP START PLANAR ...
0 !: 1 16 0 0 0 1 0 0 0 1 0 0 0 1 someotherpart.dat
0 !TEXMAP END
0 !TEXMAP END

2. Is there any intention that the texture-image paths should support absolute filepaths? We do support these for type-1 lines (although that doesn't necessarily mean we need to for textures).

3. Is it the case that you use either geometry1+geometry3 or geometry2, or can you use geometry2 in combination with either of the others?

4. The description states that "If an END command given in a sub file stops the use of a texture specified in a calling file, then that texture will be restored to use when the sub file is exited." Does this mean that you can use "0 !TEXMAP END" in a file without it being preceded (in the same file) by an "0 !TEXMAP START"?
Reply
Re: Texture Mapping extension
#62
Alex Taylor Wrote:1. Are there any meta-commands which may not appear in the geometry sections? Is, for example, nesting !TEXMAP blocks in the same file supported?

NOFILE aborts the texture. I am proposing that STEP will also implicitly abort it. http://forums.ldraw.org/showthread.php?t...90#pid6390 If there are any other metas which have multiline "scope," they should not overlap a texture. I can't think of any at the moment though.

Nesting is supported according to the spec, but really, why would you want to? (I haven't implemented support for it yet.)

Quote:2. Is there any intention that the texture-image paths should support absolute filepaths? We do support these for type-1 lines (although that doesn't necessarily mean we need to for textures).

In the interest of cross-platform compatibility and relocation on the local filesystem, I would personally discourage the use of absolute paths. I don't actually support them for Type 1 lines myself.

Quote:3. Is it the case that you use either geometry1+geometry3 or geometry2, or can you use geometry2 in combination with either of the others?

geometry1 and geometry3 are mutually exclusive when drawing the file. Geometry2 (geometry not prefixed with !Smile will be displayed unconditionally, so yes, you may use it with either of the others.

Quote:4. The description states that "If an END command given in a sub file stops the use of a texture specified in a calling file, then that texture will be restored to use when the sub file is exited." Does this mean that you can use "0 !TEXMAP END" in a file without it being preceded (in the same file) by an "0 !TEXMAP START"?

Don't do it!

Again, see my proposal at http://forums.ldraw.org/showthread.php?t...90#pid6390

Allen

P.S. I have no idea what the answer to your question about units is. I hope someone steps forward to answer.
Reply
Re: Texture Mapping extension
#63
Allen Smith Wrote:
Alex Taylor Wrote:1. Are there any meta-commands which may not appear in the geometry sections? Is, for example, nesting !TEXMAP blocks in the same file supported?

NOFILE aborts the texture. I am proposing that STEP will also implicitly abort it. http://forums.ldraw.org/showthread.php?t...90#pid6390 If there are any other metas which have multiline "scope," they should not overlap a texture. I can't think of any at the moment though.

That brings up an interesting point: whilst a NOFILE is pretty unambiguous, suppose you encounter the following code:

0 !TEXMAP START PLANAR...
0 !: <geometry>
0 STEP
0 !: <geometry>
0 !TEXMAP END

I agree that the STEP should abort the texture, but what should be done with the second block of <geometry> - and should the parser report an error when it hits what is now effectively an invalid "0 !TEXMAP END" statement?

Might it in fact be simpler to just prohibit the appearance of STEP inside a texmap block?

Quote:Nesting is supported according to the spec, but really, why would you want to? (I haven't implemented support for it yet.)

Yes, that's pretty much my take on it - it's a strange thing to need to do - but from reading the spec, the only indication I can see that nesting is permitted is when one file calls another via a type-1 line. I can't see anything that would permit (or, admittedly, prohibit) the code I gave in my last post.

Quote:
Quote:3. Is it the case that you use either geometry1+geometry3 or geometry2, or can you use geometry2 in combination with either of the others?

geometry1 and geometry3 are mutually exclusive when drawing the file. Geometry2 (geometry not prefixed with !Smile will be displayed unconditionally, so yes, you may use it with either of the others.

I'm struggling to think of a situation where you would need to use geometry2 in conjunction with the others, tbh. I can see why it exists, but to me it only makes sense if used on its own.

Quote:
Quote:4. The description states that "If an END command given in a sub file stops the use of a texture specified in a calling file, then that texture will be restored to use when the sub file is exited." Does this mean that you can use "0 !TEXMAP END" in a file without it being preceded (in the same file) by an "0 !TEXMAP START"?

Don't do it!

Again, see my proposal at http://forums.ldraw.org/showthread.php?t...90#pid6390

Yes, that's what I figured, but of course as an author I can only follow the published spec... :-)
Reply
Re: Texture Mapping extension
#66
Alex Taylor Wrote:That brings up an interesting point: whilst a NOFILE is pretty unambiguous, suppose you encounter the following code:

0 !TEXMAP START PLANAR...
0 !: <geometry>
0 STEP
0 !: <geometry>
0 !TEXMAP END

I agree that the STEP should abort the texture, but what should be done with the second block of <geometry> - and should the parser report an error when it hits what is now effectively an invalid "0 !TEXMAP END" statement?

Might it in fact be simpler to just prohibit the appearance of STEP inside a texmap block?

This is actually a question of precedence: which is the higher-level object in the file: the step, or the texture? I argue that the step has higher precedence than the texture. In other words, when parsing out the logical structure of a file, one looks first for the steps, then for the stuff inside them. When we look at the file you've shown, we see two steps, containing the following:

Step 1:
Code:
0 !TEXMAP START PLANAR...
0 !: <geometry>
Step 2:
Code:
0 !: <geometry>
0 !TEXMAP END

There's no such thing as a step "inside" a texture. There are textures inside steps. This should make sense, as everything in a model must be in a step (even if it's only an implicitly 1-step model).

So now the question is whether either of those steps contain illegal statements. In my opinion, they don't. Step #1 definitely doesn't. We already know that TEXMAP can end when it runs out of scope at the end of a file, so it's perfectly legal (though unsightly) to have a START which isn't balanced by an END.

Step #2 is more debatable. However, in the spirit of how LDraw works, unrecognized type 0 lines devolve into comments. Since neither line in Step #2 has meaning without being prefaced by a TEXMAP START, I consider them stray junk in the file rather than parsing errors.

Allen
Reply
Re: Texture Mapping extension
#68
Allen Smith Wrote:There's no such thing as a step "inside" a texture. There are textures inside steps. This should make sense, as everything in a model must be in a step (even if it's only an implicitly 1-step model).

Interesting. I hadn't considered looking at the file like that (probably because I rarely use the STEP command), but yeah, that makes sense.

Quote:So now the question is whether either of those steps contain illegal statements. In my opinion, they don't. Step #1 definitely doesn't. We already know that TEXMAP can end when it runs out of scope at the end of a file, so it's perfectly legal (though unsightly) to have a START which isn't balanced by an END.

Step #2 is more debatable. However, in the spirit of how LDraw works, unrecognized type 0 lines devolve into comments. Since neither line in Step #2 has meaning without being prefaced by a TEXMAP START, I consider them stray junk in the file rather than parsing errors.

Allen

That seems reasonable. And if you encountered this:

0 !TEXMAP START...
0 !: <geom1>
0 STEP
<geom2>
0 !TEXMAP FALLBACK
<geom3>
0 !TEXMAP END

then all three blocks of geometry will be rendered when textures are turned on, but that's fine since it's user-error.
Reply
Re: Texture Mapping extension
#70
Allen Smith Wrote:Step #2 is more debatable. However, in the spirit of how LDraw works, unrecognized type 0 lines devolve into comments. Since neither line in Step #2 has meaning without being prefaced by a TEXMAP START, I consider them stray junk in the file rather than parsing errors.

I agree. Any 0 !: lines that appear when not in the context of an active TEXMAP should be ignored. Assuming we ratify your suggestion of having STEP abort the texture, these would be ignored.
Reply
Re: Texture Mapping extension
#64
And another one...

The spec explicitly permits the quote (") character in texture-image paths. This character is not permitted in filepaths on Windows systems.

I would suggest that since this is now an official spec document, it should probably follow the same rules on filenames as in here: http://www.ldraw.org/article/512.html
Reply
Re: Texture Mapping extension
#65
Alex Taylor Wrote:And another one...

The spec explicitly permits the quote (") character in texture-image paths. This character is not permitted in filepaths on Windows systems.

I would suggest that since this is now an official spec document, it should probably follow the same rules on filenames as in here: http://www.ldraw.org/article/512.html

Not everybody uses Microsoft filesystems.

The rules on filenames from the document you cite are only applicable to files released in the official library. They most absolutely do not apply to user-generated LDraw files. Since they would already cover texture files released in the official library, I don't believe there is any additional specifying is necessary.

Allen
Reply
Re: Texture Mapping extension
#67
Allen Smith Wrote:The rules on filenames from the document you cite are only applicable to files released in the official library. They most absolutely do not apply to user-generated LDraw files. Since they would already cover texture files released in the official library, I don't believe there is any additional specifying is necessary.

Allen

D'oh! I really shouldn't post late at night... :-(
Reply
Re: Texture Mapping extension
#69
As far as I know, the units should be in degrees. The spec should be updated to reflect this. One of the design goals was to make it easy for part authors to use textures. In my opinion, using radians would go counter to this design goal.
Reply
Re: Texture Mapping extension
#71
Travis Cobbs Wrote:As far as I know, the units should be in degrees. The spec should be updated to reflect this. One of the design goals was to make it easy for part authors to use textures. In my opinion, using radians would go counter to this design goal.

Cool :-) Reading the spec, it appears that only positive values should be used - is that correct? If so, and on the assumption that specifying an angle of zero makes no sense, I'd like to see the spec make explicit the range of allowable values: for example, 0<angle<=360.
Reply
Re: Texture Mapping extension
#72
I think we left that unspecified until first implementation, so it could be experimented with and changed appropriately if any issues popped up in the initial impl.

degrees is the most likely preferred value, and it would have been degrees unless we ran into problems with that.

-- joshua
Reply
Re: Texture Mapping extension
#56
Daniel Görner Wrote:It looks impressive, although I'd like to see the figure rendered in LDView with lights turned on. Or even better, rendered with POV.

There is lighting here with the pig and then some experimental work (so the texture doesn't entirely make sense for real-world use) here with a cow part. Feel free to dig around in that album some more for other examples (note that this is all experimental, research-and-development work that's 2 years old at this point).

this shows TEXMAP parts done in POV. The one on the left has been carefully drawn as an object in Illustrator format, so the texture is scalable. The other two -- the maps -- were scanned and then had their background color removed, and then deposited directly onto the tile surface (presuming I remember the details this much later).
Reply
Re: Texture Mapping extension
#57
I was just asking, because without the lights the minifig heads I did look almost the same as yours done with texture mapping. I wanted to see if there's a difference when the lights are turned on.
Reply
Re: Texture Mapping extension
#58
Here is a shot from LDView with curve quality set to max, and lighting enabled:

[Image: xdzGx.png]

(Make sure to click through to the original image.)

Here's another shot with a different color head and different angle, making the fact that the lighting is OK more obvious:

[Image: KsGmf.png]
Reply
Re: Texture Mapping extension
#59
Daniel Görner Wrote:I was just asking, because without the lights the minifig heads I did look almost the same as yours done with texture mapping. I wanted to see if there's a difference when the lights are turned on.

From what I recall, Travis did a LOT of work on getting lighting and various other issues to work out well.

I had prepared another image of the lawn gnome with lights, but I think his examples are better than mine.

Note that the texture being used for Indy's head has "fringing" on the edges of elements as they feather out to transparent. That's due to my inexperience with exporting bitmaps in Adobe Illustrator (from 2 years ago), and later textures don't have that issue (or it's severely lessened).

-- joshua
Reply
Re: Texture Mapping extension
#40
Magnus wrote this as comment to one of my submitted parts:
"Am I missing something, or why are we creating "texture mapping", when patterns like this is created?"

Well, I think I have finally made a part that's pro texture mapping:

[Image: 6985160784_93a877230e_b.jpg]

This is still WIP but as of right now, it has gone beyond 600 KB. I think I could do that with a Hi-Res image for about a third or a quater of that size. Although I don't know which format the textures will finally be, I made a test jpeg about 2000x2000 px in size which had 300 KB. But I think a texture for a torso doesn't have to be this big and could still be considered as Hi-Res.
Reply
Re: Texture Mapping extension
#41
Just on a side note, I don't think using JPEG for textures is a good idea. Compression artifacts would ruin quality at close range.
Reply
Re: Texture Mapping extension
#42
It was just an example...

I finished the part a few minutes ago. It's 700 KB now.
Reply
Re: Texture Mapping extension
#43
Personally I couldn't care about 700K disk space, and would still prefer it over textures because of it being a vector source.

imho textures (for flat surfaces) should only be used for place holders until a real pattern is modelled.
Reply
Re: Texture Mapping extension
#44
Roland Melkert Wrote:Just on a side note, I don't think using JPEG for textures is a good idea. Compression artifacts would ruin quality at close range.

IIRC, the standard says to allow either JPEG or PNG, but I've always consistently used PNG files for all the texture mapping I've been doing. For what that's worth. I guess I agree with you, Roland.

The beauty of using Illustrator to create vector art and then output an intermediate PNG as texture is that if there is artifacting, it can usually be greatly reduced by simply outputting the texture at a higher resolution (the higher the better, subject to whatever size limitations you may want to keep on yourself versus the quality). This way, simpler textures can take up less room, and highly detailed textures more room, for required better quality.

Changing the colors in the texture also becomes pretty straightforward.

-- joshua
Reply
Re: Texture Mapping extension
#45
On a side note, is there a free equivilant of Illustrator? I'd like to keep the barriers to parts authoring fairly low and having to buy into Adobe isn't cheap.
Reply
Re: Texture Mapping extension
#46
I believe that Inkscape is designed to be a free alternative to Illustrator. I have no idea if it's any good, though.
Reply
Re: Texture Mapping extension
#50
Sadly it is not particularly good.

Tim
Reply
Re: Texture Mapping extension
#51
Tim Gould Wrote:Sadly it is not particularly good.

Tim

This might help:
http://en.wikipedia.org/wiki/Comparison_...cs_editors

Also, Philo wasn't kidding. Corel Draw has slipped in the market, and their edu pricing is pretty sweet:
http://www.amazon.com/CorelDRAW-Suite-X5...tudent/dp/

Adobe forces you to buy an entire suite (Illustrator + Photoshop), and (as of this writing) the edu pricing on it is $350.

-- joshua
Reply
Re: Texture Mapping extension
#52
I never looked into this but a while back I read something about generating sprite's with blender and gimp. Such an approach might be useable here as well.
Reply
Re: Texture Mapping extension
#47
Orion Pobursky Wrote:On a side note, is there a free equivilant of Illustrator? I'd like to keep the barriers to parts authoring fairly low and having to buy into Adobe isn't cheap.

Anything that allows output of a bitmap is going to work for texture mapping; but I do recommend a tool chain that supports vector graphics for greatest flexibility and value to the work that's done (it's so much easier to make adjustments later on). I'm sure there are all levels of tools that allow for vector graphics to be created, and a bitmap to be output based on it. The tools that were used to generate the SVG for that work are a good place to look..?

Though, to me, the value of the project lies in the fact that I can turn to my professional artist friends and talk to them in the language they understand, and they can do workflow like they understand, and there's no slowdown to the work, fewer barriers to overcome. This fits in with what Allen said here, basically that texture mapping allows those who aren't part modelers to work in a much different way, but still meaningfully contribute. I guess what I'm saying here is that this wouldn't be a barrier to "parts authoring," but rather texture generation, and that it could just as easily be looked upon as an advantage, rather than a barrier -- that professional and useful tools can be used to make low complication contributions to the cause. Adobe tools aren't cheap (nor is Corel Draw, for that matter), but I own both and do they EVER make this job so much easier and quicker to accomplish than any other existing method for LDRAW patterns!

I suggest thinking more in the mindset of how many artistic types (who are already going to know, understand, and likely own, Adobe tools) you can encourage to the cause because you've brought the mountain to them, than how many parts authors you're going to convince to work on textures using yet another open source application to learn (another mountain to climb).
Reply
Re: Texture Mapping extension
#48
Quote:Adobe tools aren't cheap (nor is Corel Draw, for that matter)
There's a Corel Draw student/hobbyist version that's not SO expensive. I've tried Inkscape too, as any new tool it requires some time getting used to it, but it's definitely a capable piece of software.
Reply
Re: Texture Mapping extension
#49
That's good. My reasoning being that if I think that Adobe products are over priced then the 15 year old graphic prodigy with a passion for Lego who works at McDonalds probably cant even dream of buying Illustrator. I want to make sure the there's a free or reasonably price piece of vector software out there.
Reply
Re: Texture Mapping extension
#74
Dear LSC,

since you're working on this please define also the restrictions for the PT such as resolution (how many pixel per LDU) or naming conventions.

I also think that some extensive examples would suit the specs page.

w.
LEGO ergo sum
Reply
Re: Texture Mapping extension
#75
Presumably the plane in PLANAR mode is supposed to be rectangular? If so, this should be made explicit in the spec.
Reply
Re: Texture Mapping extension
#76
I'm not entirely sure I understand your question.

The currently language formally requires the specified points to be three of the four corners of a rectangle. It doesn't actually state this, and I don't have any real objection to calling that out, if that's what you're asking for. However, since P1 and P2 are are both perpendicular to each other and to the texture plane, the input points must by definition be three out of four corners of a rectangle (unless I'm mis-reading).
Reply
Re: Texture Mapping extension
#77
Yeah, that's all it was - IMO the spec could be slightly clearer than is currently the case.

On a related note, though, since in practice the three points can be literally anything the user cares to type into their text-editor, is there a recommended behaviour for renderers when faced with a set of points which do not conform to the spec?
Reply
Re: Texture Mapping extension
#78
JC Tchang informs me that he created drawings explaining cylindrical and spherical mapping. These drawings can be freely used to illustrate texture mapping standard text.
[Image: cylindrical.png][Image: spherical.png]
Reply
Re: Texture Mapping extension
#79
Very nice pictures,

Just curious but when using these kind of projections do the part author compensate for the deforming in the supplied textures ? If so many of those textures would be part specific (even while being the same pattern). And since there already is some discussion about naming the textures.. Smile
Reply
Re: Texture Mapping extension
#80
Good question!
Reply
Re: Texture Mapping extension
#81
Fro memory it's pretty rare for a part to truly have print on a highly non-Euclidean surface, except minifig heads.

Do you have any examples where the same print is used on a flat and seriously curved surface? If the curve is only slight, then the print will come out pretty fine on either.

Tim
Reply
Re: Texture Mapping extension
#82
Willy Tschager Wrote:Dear LSC,
since you're working on this please define also the restrictions for the PT such as resolution (how many pixel per LDU) or naming conventions.
I also think that some extensive examples would suit the specs page.
w.
I too would like to see practical recommendations, especially about resolution. Joshua's examples provided by Travis here seem to me on the lower end, resolution wise.
I also remember seeing here a request for power of two size of images, but can't find it again???
Reply
Re: Texture Mapping extension
#83
About the power of two thing, I think you mean this comment by travis:

http://forums.ldraw.org/showthread.php?t...73#pid6573

but like I wrote in my reply to it, I don't think it's a good thing to have.
Reply
Re: Texture Mapping extension
#84
Thanks, Roland. As for resolution, I figured that a correct printing resolution is 300dpi (already pretty good for a silkscreen process!), giving a mere 189 pixels image for a 2x2 tile... In this regard, provided example are OK.
Reply
Re: Texture Mapping extension
#85
Or 192px Wink ie. 3x2x2x2x2x2x2 Big Grin
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)
Forum Jump:


Users browsing this thread: 1 Guest(s)