| Welcome, Guest |
You have to register before you can post on our site.
|
| Forum Statistics |
» Members: 4,999
» Latest member: TSAI
» Forum threads: 5,996
» Forum posts: 50,722
Full Statistics
|
| Online Users |
There are currently 375 online users.
» 1 Member(s) | 371 Guest(s)
Baidu, Bing, Google, Gerald Lasser
|
|
|
| Use of "LDraw" in the name of ldraw related programs. |
|
Posted by: Jean-Philippe Ouellet - 2011-11-26, 8:07 - Forum: All Other Programs.
- Replies (6)
|
 |
SteerCo has since voted not to allow this. See this announcement.
The day is slowly approaching when I will make my WebGL based LDraw software public.
Right now, I call it "WebGLDraw". I believe it is a clever name as it is almost a direct concatenation of the two technologies that compose it, however, I remember from reading Bricksmith years ago that internally, it calls itself MacLDraw. I believe (it's been a very long time) that I remember reading in some comment someplace in Bricksmith something about that it was going to be called MacLDraw but that the name was changed because the community had reservations about using the name LDraw... something about people possibly inferring that it was an official mac version of LDraw written by James or something... not sure. I tried to go back and find the explanation, but I was unable to, so I ask you here.
Is it ok for me to you the name WebGLDraw? Or should I name it something else? Do you have any suggestions for a name?
Also, as for Logos, is this acceptable?
![[Image: KpA4i.png]](http://i.imgur.com/KpA4i.png)
(BTW, I wrote it as an SVG, I just can't attach them here)
It was designed to look like:
![[Image: WebGL_logo.png]](https://upload.wikimedia.org/wikipedia/commons/3/39/WebGL_logo.png)
Which was in turn designed to look like:
![[Image: OpenGL_logo.jpg]](https://upload.wikimedia.org/wikipedia/en/8/8a/OpenGL_logo.jpg)
|
|
|
| Automatic matrix corrections |
|
Posted by: Roland Melkert - 2011-11-25, 19:02 - Forum: Parts Authoring
- Replies (6)
|
 |
Hello all,
I discovered rendering glitches in the Linux version of my LDCad are caused by the limited way I correct 'invalid' matrices in part files. The wrong matrices cause all kinds of lighting problems in Ubuntu 11.10 with the open source radeon driver. Yet for some reason the windows driver couldn't care less, how's that even possible?
Anyhow I'm improving the correction code, but not being a part editor or a matrix expert I'm having difficulties with it. For example I can correct these (log fragment):
Code: parts\2694.dat | line 164 | Matrix corrected from [10 0 0 0 0 0 0 0 10 ] to [10 0 0 0 1 0 0 0 10 ]
parts\2694.dat | line 165 | Matrix corrected from [-10 0 0 0 0 0 0 0 -10 ] to [-10 0 0 0 1 0 0 0 -10 ]
parts\2695.dat | line 13 | Matrix corrected from [6 0 0 0 0 6 0 0 0 ] to [6 0 0 0 0 6 0 1 0 ]
parts\2695.dat | line 14 | Matrix corrected from [6 0 0 0 0 6 0 0 0 ] to [6 0 0 0 0 6 0 1 0 ]
These all have exactly one row that's all zero's, the position for an automatic '1' can be determined quite easily.
But what about these:
Code: parts\3039p32.dat | line 40 | Invalid matrix detected [2 0 0 0 0 1.4286 0 0 -1.4286]. It could not be corrected automatically, it might cause rendering glitches.
parts\3039p32.dat | line 41 | Invalid matrix detected [2 0 0 0 0 1.4286 0 0 -1.4286]. It could not be corrected automatically, it might cause rendering glitches.
I'm guessing the middle '1.4...' should move one place to the left, but how to automatically detect and correct for this (you could also do this for the 3rd row not?).
And these are even worse I think:
Code: parts\6016.dat | line 38 | Invalid matrix detected [2.84 0 2.84 0 0 0 2.84 0 -2.84]. It could not be corrected automatically, it might cause rendering glitches.
parts\6016.dat | line 47 | Invalid matrix detected [-2.84 0 -2.84 0 0 0 2.84 0 -2.84]. It could not be corrected automatically, it might cause rendering glitches.
Or could I just put a '1' in the middle row's middle pos?, but yet again how to do a fool proof correction.
Any help would be appreciated.
Or maybe someone could just fix all the part files (just kidding  )
|
|
|
|
| Patterned parts numbers |
|
Posted by: Damien Roux - 2011-11-24, 22:56 - Forum: Parts Authoring
- Replies (6)
|
|
Hi all !
As I'm continuing to (slowly) make patterns using Stan's SVG files, a question came to my mind.
For 973 Star Wars patterns we reached 973psz. So what's next ? 973psa1, 973psa2, ... ???
|
|
|
|
| LDConfig Confusion |
|
Posted by: Tore Eriksson - 2011-11-24, 1:18 - Forum: Parts Authoring
- Replies (22)
|
|
I just downloaded the latest LDConfig.ldr from http://www.ldraw.org/library/official/LDConfig.ldr
Its header reads:
0 !LDRAW_ORG Configuration UPDATE 2011-06-03
But I already have a copy of LDConfig.ldr, and its header reads:
0 !LDRAW_ORG Configuration UPDATE 2010-06-19
This is supposed to be newer, but in the currently official but older(?), there are four more colours compared to the one I already have on my hard drive.
83 Metallic_Black VALUE #1A2831 EDGE #000000 METAL
87 Metallic_Dark_Gray VALUE #6D6E5C EDGE #5D5B53 METAL
321 Dark_Azure VALUE #078BC9 EDGE #088DCD
323 Light_Aqua VALUE #ADC3C0 EDGE #AFC9C2
What is this file dated 2011-06-19? I don't know where it comes from.
And are those four colours official standard? (I guess so since they are there in the ufficial version.)
/Tore
|
|
|
|
| I need a fast and frugal renderer |
|
Posted by: Tore Eriksson - 2011-11-23, 21:15 - Forum: LDraw Editors and Viewers
- Replies (20)
|
|
I wouldn't complain so much about every new step in the LDraw format evolution, if it wasn't that I'm 100% depending on good old L3Lab. There is absolutely no viewer or editor that comes remotely close to its speed and its resource economy. Sorry, Roland's new editor included.
But L3Lab doesn't support colours in "the forbidden zone" as I call it. This is a growing problem for me.
And L3Lab doesn't support space characters in file references either.
And almost every change in the LDraw file specs is done without the least consideration to programs like L3Lab.
I would of course compile a fast and frugal renderer myself if only I had the programming skills to do it, but that's impossible. I'm not even close to that.
Apparantly, it seems to me all focus is on nifty details and impressive effects when it comes to viewers made today. But if it was possible eleven years ago to make an LDraw viewer that still is able to produce fast renderings, wouldn't it be possible to make the same today? And support for LDConfig and the latest LDraw file specs shouldn't slow down things noticable, should it?
If somebody could produce such a viewer, I will (most likely) no longer protest against the other LDraw programs and utilities we leave behind as we "develop" (hmm?) the LDraw standard. But like I said, I still see no real alternative to L3Lab when making huge LDraw models.
/Tore
|
|
|
|
| Re: Spaces in filenames |
|
Posted by: Tore Eriksson - 2011-11-23, 16:46 - Forum: Parts Authoring
- Replies (3)
|
|
Travis Cobbs Wrote:
-------------------------------------------------------
> Michael Heidemann pointed out that the newly created OMR spec requires that filenames contain spaces,
> while the pre-existing LDraw 1.0.0 spec strongly discourages spaces or tabs in filenames.
> He (quite rightly, in my opinion) felt that this was inconsistent.
>
> So, the way I see it, we have three choices:
>
> 1. Ignore the problem.
> 2. Remove the discouragement text from the LDraw standard.
> 3. Change the OMR standard so that the filenames don't include spaces.
>
>
> My vote is to do go with option 2, at least for spaces.
I very strongly disagree. The space character is the way LDraw separates arguments.
Before taking such a giant leap in the LDraw evolution to accept spaces in file names (if so only in OMR MPD's) has anyone ever considered the consequences? How many of our programs and utilities in use will be rendered useless by this reform? Just because maybe noone in the LSC is using them doesn't mean that noone else uses and needs them.
And what if a space character is accidently placed at the end of a type one line, invisible for us humans but how will various softwares handle it? Is "3001.dat " equal to "3001.dat"? And I have this habit of normally add an extra space before the file reference, in order to make it easier to read. Will that lead to a reference to the non-existing " 3001.dat"?
/Tore
|
|
|
|
|
