LDraw.org Discussion Forums

Full Version: OMR + TEXMAPped unofficial file = ???
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5
(2018-01-05, 21:27)Roland Melkert Wrote: [ -> ]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.
(2016-01-03, 17:01)Philippe Hurbain Wrote: [ -> ]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.
(2018-03-07, 21:13)John Canepa Wrote: [ -> ]
(2016-01-03, 17:01)Philippe Hurbain Wrote: [ -> ]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.
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:

[Image: Ybt9n2P.png]

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.
(2018-03-09, 5:02)Travis Cobbs Wrote: [ -> ]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)
(2018-03-09, 19:07)Roland Melkert Wrote: [ -> ]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.

(2018-03-09, 19:07)Roland Melkert Wrote: [ -> ]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.
(2018-03-09, 20:19)Travis Cobbs Wrote: [ -> ]
(2018-03-09, 19:07)Roland Melkert Wrote: [ -> ]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.)
(2018-03-08, 0:32)Travis Cobbs Wrote: [ -> ]
(2018-03-07, 21:13)John Canepa Wrote: [ -> ]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.
(2018-03-13, 15:45)John Canepa Wrote: [ -> ]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.
(2018-01-05, 20:54)Travis Cobbs Wrote: [ -> ]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.
Pages: 1 2 3 4 5