OMR + TEXMAPped unofficial file = ???

[Philippe Hurbain]

OMR specification requires to include unofficial files (a very good thing!), but what to do when this unofficial part contains TEXMAP images? Can we imagine a way to include these images in MPD? How to make this compatible with applications that support TEXMAP (afaik LDView, LDCad, LeoCAD and Bricksmith)?

And a 2016 good new year's resolution: have TEXMAP images on Parts Tracker !

[Michael Heidemann]

This is a very good question.

At present I only can think about a file entry for the picture also! I think that the spec for MPD files already allows this. The only problem we need to solve is that the reader apps needs to be aware of that and can handle it.

just my 5 cent

[Chris Dee]

Yes, one of my aims too.

[Roland Melkert]

At present I only can think about a file entry for the picture also! I think that the spec for MPD files already allows this. The only problem we need to solve is that the reader apps needs to be aware of that and can handle it.

This would need multiple things...

1. Binairy encoding (in order to keep the mpd text based)
2. A new meta to encapsulate said data in one or multiple lines (e.g. 0 !BINDATA FJSJ2321ssdKSKL3LKdDLJSLsdaKFDJL3432LKJ21LJLSJLD.............)
3. A new mpd '0 FILE' variant to identify the subfile as a texture (e.g. 0 !BINFILE TEXMAP image.png)
4. Adjustment to the texture image lookup rules.

All this means it won't work in existing texmap supporting programs out of the box, but it won't break existing mpd support ether.

[Steffen]

a solution for embedding images into MPDs could be to use the Data URI scheme:
https://en.wikipedia.org/wiki/Data_URI_scheme
This has the advantage of
- it provides a MIME type
- it allows to use charset UTF-8
- it is text-based
- it is an already established standard (we don't have to re-invent the wheel)

For example, a small image of a red dot could be represented inside an MPD like this:

Code:

0 FILE reddot.png
0 red dot
0 Name: reddot.png
0 Author: Wikipedia
0 !DATA data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==

[Michael Heidemann]

That sounds good. But why do we need the line "Name: xxxx" and also the line above?

If the line "0 File xxxxx" contain a name with the extension ".png" then it has to be a picture with that name!

We should keep it as simple as possible.

[Steffen]

Yes, of course. The example above results from saving a dummy MPD file with MLCad and then just adding the !DATA line.

[Michael Heidemann]

Please add a simple file with picture to this thread that make use of TEXMAP. So we are able to let our thoughts flow

[Philippe Hurbain]

Exemple of a TEXMAPped part: http://www.ldraw.org/cgi-bin/ptdetail.cg...13710a.dat
Texture file attached here

  13710a.png (Size: 56.01 KB / Downloads: 166)

[Michael Heidemann]

Thank you.

Now I need to find a way to transform the picture in Visual Basic
Got it!

The DATA according to Firefox is like follows:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAlsAAAEFCAYAAADUqSJrAAAgAElEQVR4nOydd3CbVbr/c3937sydO3fuX3tnduYSYAGnhxBKElpCCQkJsIQaOlkgENgQCKEmWUIglARCKIHNEkKsYtmyLNlqli2523LvluTee3vVe/n+/nhjxYokW7Ily07OZ+aZBenV+57zSvj97DnPec4iEAiEsLDb7dBoNMiUZ4CTmIB4xnnEM86DxWZCKEpDkbIQmkYNRkZG4HK5Yt1cAoFAIMSYRbFuAIGwUPB4PGhQNSCBw.......

Sadly the code is too long for the forum.

[Rolf Osterthun]

Hey Michael,

Now I need to find a way to transform the picture in Visual Basic

that should be very easy. I think you are using .Net, so have a look at Convert.ToBase64String(Byte[]).

Rolf

[Michael Heidemann]

Yes, that is correct. Yesterday evening I also found that function .

I'll keep you informed about my progress on this in MPDCenter.

[Damien Roux]

I have some questions :

Will this replace patterns one day?
How is dedined the png resolution?
Won't iz be better to use some kind of vectorial image format instead of pixels-based one?

[Roland Melkert]

Will this replace patterns one day?

I doubt it as most patterns are fairly square and thus easy to model. In such cases the old method will offer higher quality as it is basically vector based.

How is dedined the png resolution?

There is no real limit I know of but in the practice you propably need to keep it below 1 megapixel to keep the OpenGL/directX usage universal.

Won't iz be better to use some kind of vectorial image format instead of pixels-based one?

For the low detail ones the old method offers vector quality, for very complicated things a high res texture would be good enough. But if needed we can also add other formats then png to the standard but they will be harder to implement.

[Steffen]

BTW....: we already _have_ a vectorial image format: LDRAW...
Yes, it is much simpler than e.g. SVG, but if you want to create a pattern as vector graphics - you already can..........

[Philippe Hurbain]

I dream of somebody improving on Travis SvgToDat converter...

[Damien Roux]

You mean: better traingulation?

[Philippe Hurbain]

Yes, and possibly support of more svg features (eg. paths)

[Travis Cobbs]

Wow, I totally forgot about even writing that. If anyone is interested in picking up where I left off, I'll post the source code somewhere.

[Philippe Hurbain]

Any new ideas about this? Chances for new specs? For compatible viewers/editors?

[Roland Melkert]

I think Steffen's example:

Code:

0 FILE reddot.png
0 red dot
0 Name: reddot.png
0 Author: Wikipedia
0 !DATA data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==

Is very usable/implementable. It just needs some global rules. Like, e.g.:

"when a !DATA is used in all other lines except header descriptive ones most be ignored."
"Only the image/png;base64 variant is supported."

and maybe limit the file extension, but I don't think that is actually needed as the texture can be detected by the presence of the data meta alone.

[Steffen]

- yes, we should require these restrictions
- I suggest to also allow image/jpg and image/jpeg (which mean the same)
- to avoid that all users are forced to just use 1 (potentially very long) line, we could allow that that line is splitup into multiple ones, each starting with !DATA

[Reuben Pearse]

I dream of somebody improving on Travis SvgToDat converter...

Where can I find details of the SvgToDat converter? The link on this post comes up with the message "The specified thread does not exist."

[Travis Cobbs]

I dream of somebody improving on Travis SvgToDat converter...

Where can I find details of the SvgToDat converter? The link on this post comes up with the message "The specified thread does not exist."

Here is the original post where I published my first test build (which is the only one ever) of the program:

http://forums.ldraw.org/thread-593-post-720.html#pid720

That was almost exactly 5 years ago. I'd be happy to publish the source code if anyone is interested in taking it further. The download link in that post is still valid, but you need to read the post before trying it out.

[Travis Cobbs]

Reviving this thread, I have some suggested modifications. I don't think we should make this MPD-specific. Instead, I think we should add a new !DATA meta that requires a filename prior to the base64-encoded data. The decoded contents of the base64 data would then be treated as the specified file. (In theory, an ldr file could even be encoded and then referenced, but this would be strongly discouraged.)

Also, I think we should conform to e-mail-compatible base64 encoding, meaning that we should only have 76 encoded characters per line. Each line would begin with "0 !:" (like used in !TEXMAP itself). Something like:

Code:

0 !DATA BEGIN 19204p01.png
0 !:iVBORw0KGgoAAAANSUhEUgAAAbcAAAHfCAYAAADTMJbcAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA
0 !:BGdBTUEAALGOfPtRkwAAACBjSFJNAAB6JQAAgIMAAPn/AACA6QAAdTAAAOpgAAA6mAAAF2+SX8VG
0 !:AADzUElEQVR42uz9a49tSZIdiC3bJ+JmVbM13WSzX2Q1KY4AUcIMJM1QA4wA/WF91W8QIAEDDqWR
0 !:hhwNpKHIqmZ3VbPJ5qMr80bEOaYP2x/m7vbakTez7s10L2TFjYgT57EfbraWma1FzIy99tprr732
0 !DATA END

(Note that I only included the first 4 lines of the base64-encoded version of 19204p01.png.)

It would be illegal to have a !DATA statement between a !TEXMAP BEGIN and !TEXMAP END, or immediately following a !TEXMAP NEXT.

[Roland Melkert]

Reviving this thread, I have some suggested modifications. I don't think we should make this MPD-specific. Instead, I think we should add a new !DATA meta that requires a filename prior to the base64-encoded data. The decoded contents of the base64 data would then be treated as the specified file. (In theory, an ldr file could even be encoded and then referenced, but this would be strongly discouraged.)

Also, I think we should conform to e-mail-compatible base64 encoding, meaning that we should only have 76 encoded characters per line. Each line would begin with "0 !:" (like used in !TEXMAP itself). Something like:

Code:

0 !DATA BEGIN 19204p01.png
0 !:iVBORw0KGgoAAAANSUhEUgAAAbcAAAHfCAYAAADTMJbcAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA
0 !:BGdBTUEAALGOfPtRkwAAACBjSFJNAAB6JQAAgIMAAPn/AACA6QAAdTAAAOpgAAA6mAAAF2+SX8VG
0 !:AADzUElEQVR42uz9a49tSZIdiC3bJ+JmVbM13WSzX2Q1KY4AUcIMJM1QA4wA/WF91W8QIAEDDqWR
0 !:hhwNpKHIqmZ3VbPJ5qMr80bEOaYP2x/m7vbakTez7s10L2TFjYgT57EfbraWma1FzIy99tprr732
0 !DATA END

(Note that I only included the first 4 lines of the base64-encoded version of 19204p01.png.)

It would be illegal to have a !DATA statement between a !TEXMAP BEGIN and !TEXMAP END, or immediately following a !TEXMAP NEXT.

I like the format but I still think an embedded png (or any non ldraw file) should have its own FILE section as it can be referenced from multiple models/parts.

So maybe

Code:

0 FILE 19204p01.png
0 Texture for 19204p01
0 Name: 19204p01.png
0 Author: Philippe Hurbain [Philo]
0 !LDRAW_ORG Texture UPDATE 2018-01
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

0 !DATA BEGIN
0 !:iVBORw0KGgoAAAANSUhEUgAAAbcAAAHfCAYAAADTMJbcAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA
0 !:BGdBTUEAALGOfPtRkwAAACBjSFJNAAB6JQAAgIMAAPn/AACA6QAAdTAAAOpgAAA6mAAAF2+SX8VG
0 !:AADzUElEQVR42uz9a49tSZIdiC3bJ+JmVbM13WSzX2Q1KY4AUcIMJM1QA4wA/WF91W8QIAEDDqWR
0 !:hhwNpKHIqmZ3VbPJ5qMr80bEOaYP2x/m7vbakTez7s10L2TFjYgT57EfbraWma1FzIy99tprr732
0 !DATA END

[Philippe Hurbain]

I like the proposal. I tested an mpd with an embedded image with MLCad, LDCad, MPDCenter, MPDwizard. Of course the texture didn't work, but I got no weird behaviour. Only minor drawback: if I extract mpd files, a .png is created while the file with header and uuencoded content is NOT a png file.

[Roland Melkert]

I like the proposal. I tested an mpd with an embedded image with MLCad, LDCad, MPDCenter, MPDwizard. Of course the texture didn't work, but I got no weird behaviour. Only minor drawback: if I extract mpd files, a .png is created while the file with header and uuencoded content is NOT a png file.

I expect most programs would see it as an empty model, unless they restrict the extensions for some reason.

I'm not sure about the file type specification though, using

Code:

0 !LDRAW_ORG Texture UPDATE 2018-01

Might be to restrictive as we would have to add keys for all filetypes, maybe a more generic :

Code:

0 !LDRAW_ORG Data UPDATE 2018-01

Combined with the program interpreting the file extension given in FILE or the filename itself would be enough.

You could also use, e.g.:

Code:

0 unofficial data

in mpd's etc.

Probably its only use, as official libraries should distribute the png as is, although this setup would allow for an png to be wrapped by a non .mpd .ldr named .png

[Michael Horvath]

Reviving this thread, I have some suggested modifications. I don't think we should make this MPD-specific. Instead, I think we should add a new !DATA meta that requires a filename prior to the base64-encoded data. The decoded contents of the base64 data would then be treated as the specified file. (In theory, an ldr file could even be encoded and then referenced, but this would be strongly discouraged.)

Also, I think we should conform to e-mail-compatible base64 encoding, meaning that we should only have 76 encoded characters per line. Each line would begin with "0 !:" (like used in !TEXMAP itself). Something like:

Code:

0 !DATA BEGIN 19204p01.png
0 !:iVBORw0KGgoAAAANSUhEUgAAAbcAAAHfCAYAAADTMJbcAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA
0 !:BGdBTUEAALGOfPtRkwAAACBjSFJNAAB6JQAAgIMAAPn/AACA6QAAdTAAAOpgAAA6mAAAF2+SX8VG
0 !:AADzUElEQVR42uz9a49tSZIdiC3bJ+JmVbM13WSzX2Q1KY4AUcIMJM1QA4wA/WF91W8QIAEDDqWR
0 !:hhwNpKHIqmZ3VbPJ5qMr80bEOaYP2x/m7vbakTez7s10L2TFjYgT57EfbraWma1FzIy99tprr732
0 !DATA END

(Note that I only included the first 4 lines of the base64-encoded version of 19204p01.png.)

It would be illegal to have a !DATA statement between a !TEXMAP BEGIN and !TEXMAP END, or immediately following a !TEXMAP NEXT.

Splitting to multiple lines will cause the user to have to scroll by huge amounts in programs that show the LDR source code. Is MLCAD the only program that still does this?

[Travis Cobbs]

Splitting to multiple lines will cause the user to have to scroll by huge amounts in programs that show the LDR source code. Is MLCAD the only program that still does this?

I think not splitting to multiple lines is just asking for trouble. Many text editors are likely to be unhappy with 250,000-byte lines.

[Travis Cobbs]

I like the format but I still think an embedded png (or any non ldraw file) should have its own FILE section as it can be referenced from multiple models/parts.

So maybe

Code:

0 FILE 19204p01.png
0 Texture for 19204p01
0 Name: 19204p01.png
0 Author: Philippe Hurbain [Philo]
0 !LDRAW_ORG Texture UPDATE 2018-01
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

0 !DATA BEGIN
0 !:iVBORw0KGgoAAAANSUhEUgAAAbcAAAHfCAYAAADTMJbcAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA
0 !:BGdBTUEAALGOfPtRkwAAACBjSFJNAAB6JQAAgIMAAPn/AACA6QAAdTAAAOpgAAA6mAAAF2+SX8VG
0 !:AADzUElEQVR42uz9a49tSZIdiC3bJ+JmVbM13WSzX2Q1KY4AUcIMJM1QA4wA/WF91W8QIAEDDqWR
0 !:hhwNpKHIqmZ3VbPJ5qMr80bEOaYP2x/m7vbakTez7s10L2TFjYgT57EfbraWma1FzIy99tprr732
0 !DATA END

I can't think of any reason the !LDRAW_ORG or LICENSE lines would ever be used. I'm not in any way suggested that this be used in official parts as a stop-gap measure until the parts tracker can be updated to allow textures. (Note that doing that would require approval by the LSC, since parts have an explicit list of meta commands that they are allowed to use. I for one would almost certainly vote against allowing this.) The whole point here (by my understanding) is for unofficial parts to be able to be included in an MPD.

In fact, I'm kind of dubious about having any header information in the file at all. A program generating this wrapper only has a PNG file as its input. Sure, it could prompt the user for the other info, but I think it needs to be assumed that all that info would match the file the texture is reference from. That's all that can be done with PNG texture files, so supporting more data for wrapped texture files just encourages wrapping them in situations where that is clearly not the optimal solution. And my original suggestion (not using 0 FILE) was meant to be included anywhere in a model, and then be just as global as a 0 FILE entry would be. The argument for using 0 FILE is that it's already standard, and I can accept that. But adding metadata to the MPD file entry just seems wrong to me.

[John Canepa]

Exemple of a TEXMAPped part: http://www.ldraw.org/cgi-bin/ptdetail.cg...13710a.dat
Texture file attached here

I've been reading through multiple Forum Posts, looking for Basic Texmap Instructions.  We're trying to load textures in to Bricksmith Version 3.0 (3.0) and use them for instruction creation in LPub 4.0.0.10, on a MAC Mini OS 10.  I opened your part 13710a.dat in Bricksmith to take a look, thanks for the example, and by replacing a few parts and the texture, I was able to see my texture appear in Bricksmith.
 
Once I opened your example in Bricksmith I noticed a square 4 color icon with image attached in the File Contents.  Can you explain how that's created in Bricksmith 3.0?  We're also not having any luck getting any images to show in LPub 4, using LDView, and LDGlite (preferred).  

Any help is welcome.  Thanks in advance.

[Travis Cobbs]

Exemple of a TEXMAPped part: http://www.ldraw.org/cgi-bin/ptdetail.cg...13710a.dat
Texture file attached here

I've been reading through multiple Forum Posts, looking for Basic Texmap Instructions.  We're trying to load textures in to Bricksmith Version 3.0 (3.0) and use them for instruction creation in LPub 4.0.0.10, on a MAC Mini OS 10.  I opened your part 13710a.dat in Bricksmith to take a look, thanks for the example, and by replacing a few parts and the texture, I was able to see my texture appear in Bricksmith.

Once I opened your example in Bricksmith I noticed a square 4 color icon with image attached in the File Contents.  Can you explain how that's created in Bricksmith 3.0?  We're also not having any luck getting any images to show in LPub 4, using LDView, and LDGlite (preferred).  

Any help is welcome.  Thanks in advance.

First of all, I don't know anything about the details of Bricksmith, so I don't know what's up with the icon you talk about.

As far as I know, LDGlite does not support textures. I could be wrong about this. In order for the textures to work in LDView, you need to have the PNG image file be located either in the same directory as the part's .dat file, or in a textures sub-directory of where the part is located. (The intent for official parts is that the textures will be in a textures subdirectory.)

At this point in time, creating your own custom textured parts requires a lot more knowledge than simply using a GUI to create a model. There are various instructions here on forums.ldraw.org for creating custom textured parts.

You should check to see which version of LDView LPub is using. I would recommend using the latest release (4.3). I don't remember when texture support was added, but they definitely work in LDView 4.3.

[Travis Cobbs]

Going mostly with Roland's suggestion (but without any header data), I created an MPD with an embedded checker texture (attached). It looks like this when opened:



Some notes about my implementation:

• I changed BEGIN to START to be consistent with !TEXMAP.
  
• I only support START/END, not NEXT.
  
• I'm only officially supporting !DATA in MPD files (since that's the whole point).
  
• Only one !DATA entry is allowed per 0 FILE entry in the MPD.
  
• When parsing the BASE64 text, I ignore any characters that aren't in the BASE64 character set, so a space after the 0 !: shouldn't break my parser.
  

[Roland Melkert]

Some notes about my implementation:

• I changed BEGIN to START to be consistent with !TEXMAP.
  
• I only support START/END, not NEXT.
  
• I'm only officially supporting !DATA in MPD files (since that's the whole point).
  
• Only one !DATA entry is allowed per 0 FILE entry in the MPD.
  
• When parsing the BASE64 text, I ignore any characters that aren't in the BASE64 character set, so a space after the 0 !: shouldn't break my parser.
  

Looks simply enough, makes me want to implement it in LDCad too.

Ignoring characters might be a problem for some parser implementations as they are usually hidden from the programmer. So I think we should state in the spec the !DATA content should be trimmed while reading but must be all base64 in the middle.

We also might need to force a multiple of 3 characters per line as base64 is grouped by 24 bits (hence the 1 or 2 trailing '=' chars)

[Travis Cobbs]

Ignoring characters might be a problem for some parser implementations as they are usually hidden from the programmer. So I think we should state in the spec the !DATA content should be trimmed while reading but must be all base64 in the middle.

I'm perfectly fine with saying that the BASE64 data cannot contain internal garbage, but have optional white space after the !:, and optional white space after the BASE64 data on each line.

We also might need to force a multiple of 3 characters per line as base64 is grouped by 24 bits (hence the 1 or 2 trailing '=' chars)

Actually, that's 4, since BASE64 encodes 6 bits per ASCII character, to yield 3 binary bytes per 4 ASCII characters. LDView will give an error if the BASE64 input length is not an even multiple of 4.

[Travis Cobbs]

We also might need to force a multiple of 3 characters per line as base64 is grouped by 24 bits (hence the 1 or 2 trailing '=' chars)

Actually, that's 4, since BASE64 encodes 6 bits per ASCII character, to yield 3 binary bytes per 4 ASCII characters. LDView will give an error if the BASE64 input length is not an even multiple of 4.

I also don't think that we should care about how many BASE64 characters are on each line. What matters is that the whole BASE64 block is an even multiple of 4 characters. I don't think decoding the data line-by-line is a good idea. (My implementation concatenates all the BASE64 data into one block and then decodes it.)

[John Canepa]

I've been reading through multiple Forum Posts, looking for Basic Texmap Instructions.  We're trying to load textures in to Bricksmith Version 3.0 (3.0) and use them for instruction creation in LPub 4.0.0.10, on a MAC Mini OS 10.  I opened your part 13710a.dat in Bricksmith to take a look, thanks for the example, and by replacing a few parts and the texture, I was able to see my texture appear in Bricksmith.

Once I opened your example in Bricksmith I noticed a square 4 color icon with image attached in the File Contents.  Can you explain how that's created in Bricksmith 3.0?  We're also not having any luck getting any images to show in LPub 4, using LDView, and LDGlite (preferred).  

Any help is welcome.  Thanks in advance.

First of all, I don't know anything about the details of Bricksmith, so I don't know what's up with the icon you talk about.

As far as I know, LDGlite does not support textures. I could be wrong about this. In order for the textures to work in LDView, you need to have the PNG image file be located either in the same directory as the part's .dat file, or in a textures sub-directory of where the part is located. (The intent for official parts is that the textures will be in a textures subdirectory.)

At this point in time, creating your own custom textured parts requires a lot more knowledge than simply using a GUI to create a model. There are various instructions here on forums.ldraw.org for creating custom textured parts.

You should check to see which version of LDView LPub is using. I would recommend using the latest release (4.3). I don't remember when texture support was added, but they definitely work in LDView 4.3.

Thanks for the reply.  I am now using LDview 4.3.  I can see my textures in Bricksmith, and in LDview, but still can't see them in LPub 4.  I updated the path to LDview, and it's now my is my selected renderer.  Again, any assistance is greatly appreciated.

[Travis Cobbs]

Thanks for the reply.  I am now using LDview 4.3.  I can see my textures in Bricksmith, and in LDview, but still can't see them in LPub 4.  I updated the path to LDview, and it's now my is my selected renderer.  Again, any assistance is greatly appreciated.

It's possible that LPub4 copies the part file into its cache while rendering, in which case the texture would not be copied, which would lead to it not showing. Try putting your textured part file in <LDraw Dir>/Unofficial/parts, and the texture in <LDraw Dir>/Unofficial/parts/textures.

[Orion Pobursky]

Reviving this thread, I have some suggested modifications. I don't think we should make this MPD-specific. Instead, I think we should add a new !DATA meta that requires a filename prior to the base64-encoded data. The decoded contents of the base64 data would then be treated as the specified file. (In theory, an ldr file could even be encoded and then referenced, but this would be strongly discouraged.)

Also, I think we should conform to e-mail-compatible base64 encoding, meaning that we should only have 76 encoded characters per line. Each line would begin with "0 !:" (like used in !TEXMAP itself). Something like:

Code:

0 !DATA BEGIN 19204p01.png
0 !:iVBORw0KGgoAAAANSUhEUgAAAbcAAAHfCAYAAADTMJbcAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA
0 !:BGdBTUEAALGOfPtRkwAAACBjSFJNAAB6JQAAgIMAAPn/AACA6QAAdTAAAOpgAAA6mAAAF2+SX8VG
0 !:AADzUElEQVR42uz9a49tSZIdiC3bJ+JmVbM13WSzX2Q1KY4AUcIMJM1QA4wA/WF91W8QIAEDDqWR
0 !:hhwNpKHIqmZ3VbPJ5qMr80bEOaYP2x/m7vbakTez7s10L2TFjYgT57EfbraWma1FzIy99tprr732
0 !DATA END

(Note that I only included the first 4 lines of the base64-encoded version of 19204p01.png.)

It would be illegal to have a !DATA statement between a !TEXMAP BEGIN and !TEXMAP END, or immediately following a !TEXMAP NEXT.

Travis, can you formalize this into a proposed change to the spec. I'd like to go this route or just change the OMR to state that an image download is required.

[Travis Cobbs]

Travis, can you formalize this into a proposed change to the spec. I'd like to go this route or just change the OMR to state that an image download is required.

Done.

[Lasse Deleuran]

Going mostly with Roland's suggestion (but without any header data), I created an MPD with an embedded checker texture (attached). It looks like this when opened:



Some notes about my implementation:

• I changed BEGIN to START to be consistent with !TEXMAP.
  
• I only support START/END, not NEXT.
  
• I'm only officially supporting !DATA in MPD files (since that's the whole point).
  
• Only one !DATA entry is allowed per 0 FILE entry in the MPD.
  
• When parsing the BASE64 text, I ignore any characters that aren't in the BASE64 character set, so a space after the 0 !: shouldn't break my parser.
  

I am trying to make this example work with the web-renderer and I have an issue with the cylindrical definition - particularly in how the third point is placed.

In the example you share, the points are:
p1 = (0,10,0)
p2 = (0,75,0)
p3 = (0,0,-40)

According to the definition on: https://www.ldraw.org/documentation/ldraw-org-file-format-standards/language-extension-for-texture-mapping.html

The points should be interpreted as defining the cylinder with bottom center being p1, top center being p2. p3 is a position on the cylinder where the bottom center of the texture resides. 

However. Since p3 has 0 as the Y-ccordinate, and the cylinder is defined to be between y=10 and y=75, this point is not 'on the cylinder'. My question is how to interpret this position and compute the texture correctly: Should I use p3 in the calculations as if everything is fine, or should I project p3 onto the plane defined by normal (p1p2) and p1 being on the plane?

It turns out that projecting p3 onto the base of the cylinder renders a result consistent with other viewers, but this should really be mentioned in the standard.


Edit: It is fixed now. It turns out that flipY=true is default when importing textures using Three.js. Now I just have to fix the UV wraparound issue mentioned elsewhere which you have fought with back in 2011.

[Roland Melkert]

However. Since p3 has 0 as the Y-ccordinate, and the cylinder is defined to be between y=10 and y=75, this point is not 'on the cylinder'. My question is how to interpret this position and compute the texture correctly: Should I use p3 in the calculations as if everything is fine, or should I project p3 onto the plane defined by normal (p1p2) and p1 being on the plane?

Neither interpretation gives me the result that you are showing, so I am wondering how you arrived at it.

The spec is a bit vague, but during LDCad's development I discovered it doesn't really matter where p3 is Y-wise.

Just use p3 to calculate a direction vector perpendicular to the p1 p2 vector.

And then use that vector to project the texture to the cylinder's surface by getting the angle between it and similar directional vector pointing at a vertex' position.

[Lasse Deleuran]

The spec is a bit vague, but during LDCad's development I discovered it doesn't really matter where p3 is Y-wise.

Just use p3 to calculate a direction vector perpendicular to the p1 p2 vector.

And then use that vector to project the texture to the cylinder's surface by getting the angle between it and similar directional vector pointing at a vertex' position.

This was also the conclusion I ended up at. Thankfully the test cases from you and others has helped me a lot arriving at this.

The issue with the specification regarding p3 is that it is not vague, but says that it corresponds to the bottom center of the texture, which is incorrect. It would be better if the specification mirrored what you just wrote.

[Lasse Deleuran]

Going mostly with Roland's suggestion (but without any header data), I created an MPD with an embedded checker texture (attached). It looks like this when opened:



Some notes about my implementation:

• I changed BEGIN to START to be consistent with !TEXMAP.
  
• I only support START/END, not NEXT.
  
• I'm only officially supporting !DATA in MPD files (since that's the whole point).
  
• Only one !DATA entry is allowed per 0 FILE entry in the MPD.
  
• When parsing the BASE64 text, I ignore any characters that aren't in the BASE64 character set, so a space after the 0 !: shouldn't break my parser.
  

I have now implemented the projections in the web renderer project (buildinginstructions.js - branch 'texmap' on github)

In order to create this screenshot:

I had to deviate from the specification regarding the V-projection for spherical. Instead of having the plane P2 containing p1, p2 and a point along the normal of P1, P2 is computed using p and the projection from p onto P1.

Should the spec be updated, or are we all implementing this incorrectly?

[Travis Cobbs]

I had to deviate from the specification regarding the V-projection for spherical. Instead of having the plane P2 containing p1, p2 and a point along the normal of P1, P2 is computed using p and the projection from p onto P1.

Should the spec be updated, or are we all implementing this incorrectly?

I'm not sure I fully understand. I think perhaps the existing wording is ambiguous, but not necessarily wrong. P1 has an infinite number of normals. Unless I'm misremembering, the intent is to take one of those normals that originates along the line between p1 and p2, move along that normal some arbitrary distance, and use that point (along with p1 and p2) as the third point for P2. So, for example, add the normal vector for P1 to p1 to obtain the third point to construct P2.

[Lasse Deleuran]

I'm not sure I fully understand. I think perhaps the existing wording is ambiguous, but not necessarily wrong. P1 has an infinite number of normals. Unless I'm misremembering, the intent is to take one of those normals that originates along the line between p1 and p2, move along that normal some arbitrary distance, and use that point (along with p1 and p2) as the third point for P2. So, for example, add the normal vector for P1 to p1 to obtain the third point to construct P2.

That is also how I understand it. However. It doesn't matter which normal of P1 we take, P2 will still be well-defined based on this choice. This is the current content of the spec:

Code:

x1 y1 z1 x2 y2 z2 x3 y3 z3 a b

The first point represents the center of the sphere. The second point represents a point on the sphere where the center of the texture map will touch. The third point is used to form a plane (P1) that is perpendicular to the texture and bisects it horizontally. An additional plane (P2) can be computed by using points 1 and 2 and generating a 3rd point along the normal of P1. P2 will be perpendicular to both P1 and the texture and will bisect the texture vertically. The two angles indicate the extents of the sphere that get mapped to. These are –a/2 to a/2 and –b/2 to b/2 as measured relative to the vector from point 1 to point 2 and within the planes P1 and P2 respectively.

Now to map world coordinates to texture coordinates, U is given by the angle between the vector formed by points 1 and 2 and the vector formed by point 1 and a world point that has been projected to the plane P1. The angle is divided by "a" to normalize it to between 0 and 1. V is given by the angle between the vector formed by points 1 and 2 and the vector formed by point 1 and a world point that has been projected to the plane P2. The angle is divided by "b" to normalize it.

As I understand it we have the three points p1, p2 and p3 and the two planes P1 and P2:

- p1 is the center of the sphere.

- p2 is the point on the surface on the sphere from where the center of the texture will be mapped.

- p3 is used to define P1 by having p1, p2 and p3 lie on P1. We thus get U for a point p by taking the projection point q1 of p onto P1 and compute the angle between p1p2 and p1q1 before normalising by dividing with the factor a. Furthermore, I can compute a normal of P1 as the cross product between p1p2 and p1p3. Let's call such a normal N1. P1 can thus be defined by N1 and a point on it (any of p1, p2 and p3).

- P2 is constructed similarly by having p1 and p2 on it, but the third point is taken along a (non-zero) normal of P1. Since "P2 will be perpendicular to both P1 and the texture and will bisect the texture vertically", P2 is well defined: You can compute a normal N2 as the cross product between p1p2 and N1.

- Given a point p, we let q2 be its projection onto P2. The value V is then computed as the angle between p1p2 and p1q2 divided by the scaling factor b.


If we follow the logic above, the vertical lines of the texture on the sphere will move downward as we move from the middle toward the red dot. In order to get the screenshots posted here, we will have to place P2 so that p1, p and q1 lie on it. However. According to the specification, P2 should be placed independently of p.

[Travis Cobbs]

I'm sorry, but I'm still not picturing what you  are trying to say, and I still don't see the problem. I'm not saying that you are wrong, I'm just saying that I don't understand. I have attached a file with some extra geometry. The red triangle uses p1, p2, and p3 from the TEXMAP definition. The green square extends that out into an easily seen square around the whole sphere representing P1 from the spec. The blue square represents P2 from the spec as I read the spec. Could you edit the model to move any of the extra geometry to represent what you think the spec says?

[Lasse Deleuran]

I'm sorry, but I'm still not picturing what you  are trying to say, and I still don't see the problem. I'm not saying that you are wrong, I'm just saying that I don't understand. I have attached a file with some extra geometry. The red triangle uses p1, p2, and p3 from the TEXMAP definition. The green square extends that out into an easily seen square around the whole sphere representing P1 from the spec. The blue square represents P2 from the spec as I read the spec. Could you edit the model to move any of the extra geometry to represent what you think the spec says?

Good idea. Consider the two points A and B on the surface of the sphere:


The 'V' components of the UV mapping for these two points is computed by taking their projections onto P2. Let qA be the projection for A onto P2 and qB be the projection of B onto P2:



Let VA be the V component of the UV mapping for A, and VB be the V component of the UV mapping for B where we ignore the scaling factor b:

VA = angle between p1p2 and p1qA

VB[color=#333333][size=small][font=Tahoma, Verdana, Arial, sans-serif] = angle between p1p2 and p1qB

As you can see on the second figure, these angles are not euqal. The projection of the texture should thus not portray the two points at the same height. In fact, following the specification to the word will result in this projection:


[/font][/size][/color]

[Travis Cobbs]

OK, I finally think I understand. I think what we really want to do is rotate the arbitrary p1pn vector around the sphere's axis until it lies on P2, and then measure the resulting angle between p1p2 and p1pn'. Does that sound right? And if so, do you have a suggestion on the best way to describe that in the spec?