| Welcome, Guest |
You have to register before you can post on our site.
|
| Forum Statistics |
» Members: 4,089
» Latest member: Grigorev
» Forum threads: 5,532
» Forum posts: 47,525
Full Statistics
|
| Online Users |
There are currently 516 online users.
» 3 Member(s) | 509 Guest(s)
Bing, Facebook, Google, Yandex, Bertrand Lequy, Kike
|
| Latest Threads |
new dual molded hairpiece...
Forum: Part Requests
Last Post: Sylvain Sauvage
4 hours ago
» Replies: 2
» Views: 341
|
Custom parts/stickers for...
Forum: Help
Last Post: N. W. Perry
8 hours ago
» Replies: 5
» Views: 298
|
Viking Creature Heads
Forum: Part Requests
Last Post: Jeff Jones
11 hours ago
» Replies: 4
» Views: 100
|
LDCad 1.7 Beta 1 (win+lin...
Forum: LDraw Editors and Viewers
Last Post: Cam's Bricks
Yesterday, 20:20
» Replies: 57
» Views: 11,697
|
Model Team
Forum: Official Models
Last Post: Marc Giraudet
Yesterday, 18:52
» Replies: 27
» Views: 25,881
|
New meta in LDConfig for ...
Forum: LDraw Editors and Viewers
Last Post: Roland Melkert
Yesterday, 17:29
» Replies: 2
» Views: 291
|
Middle mouse button
Forum: LDraw Editors and Viewers
Last Post: Roland Melkert
Yesterday, 17:25
» Replies: 4
» Views: 122
|
OMR down?
Forum: General LDraw.org Discussion
Last Post: Orion Pobursky
Yesterday, 1:42
» Replies: 7
» Views: 1,205
|
Part Request 1993 Dreamzz...
Forum: Part Requests
Last Post: Rene Rechthaler
2024-05-08, 21:08
» Replies: 3
» Views: 879
|
Suffix codes
Forum: Official File Specifications/Standards
Last Post: Orion Pobursky
2024-05-08, 17:47
» Replies: 1
» Views: 117
|
|
|
| A JavaScript .dat to .obj converter, for use online |
|
Posted by: Mike "Pomax" Kamermans - 2012-12-31, 20:42 - Forum: LDraw File Processing and Conversion
- No Replies
|
 |
Hi all,
I wrote a JavaScript .dat to .obj converter for use online with things like cubicvr.js and other WebGL rendering libraries - it's free to use, with the source code on https://github.com/Pomax/WebGLdraw (feel free to fork!)
If you spot anything that can do with improvements (like where to look for parts and subparts, for instance) let me know, or if you'd rather fix the code yourself and do a pull request with your better version: also good!
- Pomax
NB: I found testing the result of the converter easiest by running it through GLSViewer, since I'm on windows (it's a tiny 394kb utility for viewing .obj models)
|
|
|
| Writing .dat to .obj converter in JS, but having BFC problems |
|
Posted by: Mike "Pomax" Kamermans - 2012-12-30, 20:16 - Forum: LDraw File Processing and Conversion
- Replies (7)
|
|
I'm writing a .dat to .obj converter in JavaScript so I can do LEGO modelling using WebGL, and the following the documentation for data interpreting is pretty straight forward, except I'm gettting weird looking inverted faces when loading several parts.
So, I took part 75535 (technic pin joiner round) and commented off the parts after the initial two inner cylindrical surfaces. This turns it into the following extremely simple .dat file:
75535.dat reduced version Wrote:0 BFC CERTIFY CCW
0 BFC INVERTNEXT
1 16 18 0 0 0 -16 0 6 0 0 0 0 6 4-4cyli.dat
0 BFC INVERTNEXT
1 16 -18 0 0 0 16 0 6 0 0 0 0 6 4-4cyli.dat
They're both inner cylinders, with the same definition, so they should both face the same direction. However, one part faces inward (correctly) and the other part faces outward (incorrectly): http://www.int13h.com/webgl/matviewer/testParse.html (four meshes, twice, visualisation of this .obj definition is at http://www.int13h.com/webgl/matviewer for the duration of this thread)
Viewing the .dat file in LDView shows two cylinders, facing inward, so the .dat file is interpreted correctly by .dat readers. However, the converted .obj data is very wrong. Somehow my parser is screwing up, but at this point the only thing I can think of is that the RT matrix for the include operation is doing something really funky, flipping the vertices to effect a reversed winding or something. I'm kind of at my wits end, following the documentation is apparently not enough to interpet the .dat format... what am I still missing here?
- Pomax
N.B: parser code is in http://www.int13h.com/webgl/matviewer/DATParser.js
|
|
|
|
| LDraw.org 2012-03 Parts Update Now Available |
|
Posted by: Chris Dee - 2012-12-28, 18:12 - Forum: LDraw.org Announcements
- Replies (14)
|
|
The 2012-03 LDraw Parts Update has been now been released. This update includes 564 new files in the core library, including 354 new parts and 56 new primitives.
As ever, thanks are due to the small community of part authors who created or corrected parts for this release and to those who have reviewed files in order to make this release happen.
You can preview the new parts in 2012-03 and download the update by going to the Latest Parts page.
Most of the 113 certified files remaining on the LDraw Parts Tracker were held back from this update in keeping with our normal practice of not releasing new primitives or subparts until they are needed for an official part file.
|
|
|
|
| Parts Tracker |
|
Posted by: Michael Heidemann - 2012-12-26, 18:36 - Forum: Website Suggestions/Requests/Discussion
- Replies (6)
|
 |
It would be very helpful if the PT reports in any case the occurence of a given filename in the official library such as:
Code: However, 52031.dat does exist in the Official LDraw Parts library.
Today we get this information only if no entry on the PT matches the search criteria.
I would like to see this information if I enter a number with or without the extension.
|
|
|
|
| LSynth result dependent on absolute position |
|
Posted by: Ignacio Fernandez Galvan - 2012-12-26, 15:16 - Forum: All Other Programs.
- Replies (2)
|
|
Consider this simple file:
Code: 0 SYNTH BEGIN ELECTRIC_CABLE 7
0 SYNTH SHOW
1 1 40 10 0 0 1 0 -1 0 0 0 0 1 LS04.dat
1 1 10 0 0 0 1 0 -1 0 0 0 0 1 LS04.dat
1 1 0 0 0 0 1 0 -1 0 0 0 0 1 LS04.dat
0 SYNTH END
0 SYNTH BEGIN ELECTRIC_CABLE 7
0 SYNTH SHOW
1 1 40 10 500 0 1 0 -1 0 0 0 0 1 LS04.dat
1 1 10 0 500 0 1 0 -1 0 0 0 0 1 LS04.dat
1 1 0 0 500 0 1 0 -1 0 0 0 0 1 LS04.dat
0 SYNTH END
The two portions are exactly the same, the second is just displaced +500z. When processed with LSynth, however, the first portion generates only 24 lines, while the second generates 2911 lines!
I guess this is due to rounding errors and matrix transformations being referred always to (0,0,0), but can it be fixed (other than by splitting the code in two parts)?
|
|
|
|
|
