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?

As has been mentioned in the past, a fair bit of work has been put in behind the scenes to create a texture mapping extension for LDraw. The original work was done by Joshua Delahunty, and then a bunch of back and forth work was done between him and me after he contacted me and I worked on supporting the extension in LDView.

I've been meaning to bring it up here with the LSC for discussion for a long time now, and just never got around to it. Well, I finally got around to converting the specification Word Document that Joshua sent me to HTML, and I feel that LDView is at a point where it can be used as a proof-of-concept renderer for LDraw parts with textures. So, now I'd like us to discuss the extension as it exists now, and work towards getting it ratified.

The current specification (written mostly by Joshua, I think, but edited by me to remove certain features) is here. (I was going to put it into the LSC scratch pad, but ldraw.org was going so painfully slow that I decided not to.)

My development LDView (hopefully) conforms to the above specification. Additionally, a number of files have already been created that conform to this specification by Joshua. A sample of some of them are available here. Because of this, I'd like to request that syntax changes only be made if a relatively major problem is found with the current syntax. I realize this isn't normally how the LSC works, but it seemed that there was little hope of getting this ratified without a working sample implementation, and doing that involved a lot of work.

Obviously, you cannot view the above sample files with any current official LDraw viewer. However, I am currently in the process of releasing LDView 4.2 Beta 1, and have uploaded the installers to SourceForge.net. You can find them below.

Windows 32 bit

Windows 64 bit

Mac Intel 32/64 bit

Linux 32 bit .deb

Linux 64 bit .deb

Some notes. The Linux versions were built using Ubuntu 11.10. They may or may not work on any other Linux versions. The Mac version probably requires Snow Leopard or later. Please let me know if you try it on Leopard or earlier.

The original specification Word Document I got from Joshua Delahunty is here. In addition to some formatting changes, I removed the description of the CYLINDRICAL projection method, and removed its optional GLOSSMAP. Based on the recent discussion of filenames in type 1 lines, I don't think that the syntax for gloss maps was appropriate. If gloss maps are added as a future feature, I would expect them to be in a subsequent !TEXMAP line with a new command. Finally, I removed the OpenGL sample code. That sample code should probably go somewhere, but I don't think the official spec is the right place for it.

Note: I added LSC: to the thread title to differentiate it in the recent messages list from the thread in the public group. I did this to all messages in the thread, which is why I'm listed as the last editor on them. I did NOT change the text of any of the other messages.

I would like to see 41897.
Due to the fact, that I don't own this tire, I can not give a try to create it by myself :-(

Thanks

Max

edit: title changed

1. Is it possible to extract patterns out of LDD files, and if yes, how?
2. Is there a program like LDView for LDD files (so if 1 is answered with no, I could look at the patterned parts, make screenshots and use these as templates).

(coming back from http://forums.ldraw.org/showthread.php?t...92#pid3992
and from BlueBrick software which needs a unique URL of rendered images of official parts

I just noticed that we might be wasting disk space on our peeron.com / ldraw.org server unnecessarily:

We seem to currently host all images duplicatedly, compare these:

http://media.peeron.com/ldraw/images/1/u9234c01.png
http://www.ldraw.org/library/official/im...234c01.png

I think that for rendered images, just 1 instance should be sufficient.
That instance should be a ldraw.org address,
as that is the official part source, and so should be for their images.

I think peeron.com could drop their own renderings then.

Is there somewhere documentation on where official images are located?
For example, are there other renderings available, different than 100 pixels wide?

It also appears to me that the recent out of disk space problems
were caused by the renderings of the new part files:
You can check that by seeing that an image
http://www.ldraw.org/library/official/im...234c01.png
exists and has been created on the server, but another one
http://www.ldraw.org/library/official/im...00/992.png
is missing.

I also feel the color 16 renderings
http://www.ldraw.org/library/official/im...234c01.png
missing.

It appears to me that the image generation has been halted somewhere inmidst the generation
of images for update 2012-01.

For efficiency, I suggest to put all the images to a separate server, e.g.
renderedparts.ldraw.org
, thus, other pages downloading these will not impact the performance of the parts tracker negatively.

Also, the generation of these images should be done on a different machine
and simply be uploaded to the server, instead of generating them directly on the server.

To sum this up:
(1) shall we get of the duplicates?
(2) can the images for 2012-01 be completed, please?
(3) what's the official URL for them?
(4) shall we move the images to a different server?
(5) shall the image generation process be put onto a different machine than the web server for them?

When I'm viewing a model in LDView, there are always gaps between the parts. There are no gaps in MLCad, only when I view models (not only mine, but every model I tried) in LDView. The problem is, that LDView exports these gaps to POV-Ray, too. Is there an error in LDView, or ist something else in my software?

Please vote on the proposal below. Please modify the Subject to include your name and vote, in addition to giving your vote in the text.

Quote:Line Termination

All lines in the file must use the standard DOS/Windows line termination of <CR><LF> (carriage return/line feed). The last two bytes of the file must be <CR><LF>. (In other words, there must be a <CR><LF> line terminator at the end of the last line in the file.)

Quote:It is recommended that all LDraw-compliant programs also be capable of reading files with the standard Unix line termination of <LF> (line feed).

Chris,

I'd like to see "Canvas" added to the !CATEGORY list.

Thx,

w.

Chris,

there are just 4 NonCA parts left. What is their status and when can we expect to get rid off them?

w.

Does anyone know which brown to use for the belt? No brown color I tried fits. How about using custom colors in LDraw files?