Welcome, Guest |
You have to register before you can post on our site.
|
Forum Statistics |
» Members: 5,152
» Latest member: DKumar
» Forum threads: 6,079
» Forum posts: 51,232
Full Statistics
|
Online Users |
There are currently 522 online users. » 2 Member(s) | 517 Guest(s) Baidu, Bing, Google, Jeff Jones, Mark Kennedy
|
Latest Threads |
Modulex parts
Forum: Parts Authoring
Last Post: Philippe Hurbain
2 hours ago
» Replies: 26
» Views: 3,922
|
Parts we are Working on -...
Forum: Part Requests
Last Post: Jeff Jones
3 hours ago
» Replies: 157
» Views: 149,500
|
Friends 2014
Forum: Official Models
Last Post: Takeshi Takahashi
Yesterday, 16:20
» Replies: 18
» Views: 16,483
|
LDCAD about Add custom p...
Forum: LDraw Editors and Viewers
Last Post: Nate87
Yesterday, 8:13
» Replies: 5
» Views: 3,141
|
Hi-res logo primitives
Forum: Official File Specifications/Standards
Last Post: Jens Brühl
2025-07-10, 20:40
» Replies: 16
» Views: 1,020
|
Part 5561, Door 1 x 4 x 1...
Forum: Part Requests
Last Post: Gerald Lasser
2025-07-10, 9:55
» Replies: 1
» Views: 232
|
LDConfig Update: More dis...
Forum: Official File Specifications/Standards
Last Post: Jeff Jones
2025-07-09, 20:46
» Replies: 7
» Views: 446
|
bizzare minifig variants
Forum: Parts Authoring
Last Post: Jeff Jones
2025-07-09, 11:11
» Replies: 0
» Views: 114
|
Wookiees!
Forum: Part Requests
Last Post: Jeff Jones
2025-07-08, 16:48
» Replies: 0
» Views: 171
|
Colour Request: 15 Lemon ...
Forum: Official File Specifications/Standards
Last Post: Chris Böhnke
2025-07-08, 15:58
» Replies: 9
» Views: 589
|
|
|
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
|
|
|
Exporting Ldraw to Blender 3d and other 3d software problems |
Posted by: Bartholomew Lim - 2011-11-23, 11:11 - Forum: LDraw File Processing and Conversion
- Replies (5)
|
 |
I am a guy making LEGO CGI films and every time when i tried my ldraw file to Blender 3D It fails. I've tried every method :
1. Download the LDraw import Python script for Blender from http://web.tiscali.it/ALV/blender/ but It didn't work niether 2.5 and 2.4 version It just have weird dots where the bricks should be.
2. I used leocad to make LDraw files to 3ds file. It worked but LEOCad didn't have that much of an color pallet that MLCad has. All the color that leocad didn't have just turned to black and it was just chaotic to fix every color close to what I anticipated.
3. It turns out that LDview had 3ds export script and I was delighted of it. However when I tried to import in Blender it won't let me do it. Blender stops functioning and responding.
Furious of these bugs and glitches I threw my mouse and it 's broken. Would somebody help me please!!!
By the way Ldraw.org, please put WORKING 3ds export format in MLCad and LDview. Please I beg you!!!!!!!
If anyone has a solution or has simillar problems please answer this message NOW PLEASE!!!!!!!!
|
|
|
|