| Welcome, Guest |
You have to register before you can post on our site.
|
| Forum Statistics |
» Members: 5,326
» Latest member: Raina
» Forum threads: 6,185
» Forum posts: 51,827
Full Statistics
|
| Online Users |
There are currently 246 online users.
» 1 Member(s) | 240 Guest(s)
Applebot, Bing, Google, Internet Archive, Yandex, N. W. Perry
|
|
|
| There'sa problem with part 527.dat |
|
Posted by: Bertrand Lequy - 2021-03-26, 18:00 - Forum: Parts Tracker Discussion
- Replies (3)
|
 |
Hi, I suppose the matter comes from hi-res primitives, but when I open this file with LDview, and when I render it with pov-ray this helmet is hollowed, and some conditionnal lines don't match the trianlgles.
Problem disappear when I uncheck the primitives substitution.
Or is it a LDView problem I should post in Viewer's subforum ?
|
|
|
| Rounding Errors in primitives? |
|
Posted by: Tery Hamer - 2021-03-25, 18:42 - Forum: Official File Specifications/Standards
- Replies (23)
|
 |
I'm a newbie, so I am nervous about asking... can someone confirm that either A) I'm talking BS, or B) there are rounding errors in the Official LDraw Primitive .dat files?
These are mostly derived from PrimGen2 (- but I haven't checked all). Some of these files are perhaps 10 years old. Has anybody noticed this before?
AKAIK the standard is for the vectors in .dat files to be shown to 4 decimal places, removing trailing zeros.
For Rings, Cones the vector points for higher values of radii are a multiple of the cos/sin values of the segment angles times the radius. However, it would appear that the rounding is carried out on the cos/sin for the base radius (1, as used for Circle, Disc, etc), and <then> multiplied. That would be a No-No. For the base and lower radii, the error may be only 0.0001 in a few cases. But for the higher radii, these rounding errors mount up and impact the third decimal position.
So, BS or BUG?
tery
|
|
|
|
| New 64 Bit AIOI ready for testing |
|
Posted by: Willy Tschager - 2021-03-22, 11:44 - Forum: All Other Programs.
- Replies (3)
|
 |
Hi,
I compiled a 64 Bit version of the LDraw All-In-One-Installer and would appreciate if you could give it a try. The 64 Bit version installs exclusively 64 Bit programs:
LDCad
LeoCad
LPub3D
LDview
along with the usual goodies such as offline catalogue, models and links. Once this is published the 32 Bit AIOI will contain the rest of the progs such as MPDCenter or MLCad.
Please report if you run into issues with the new installer (which will be updated with the latest versions prior release):
www.holly-wood.it/tmp/LDraw_AIOI_2020-03_setup_64bit_v1.exe
w.
|
|
|
|
| ldr to pov export error |
|
Posted by: Bertrand Lequy - 2021-03-17, 14:59 - Forum: LDraw Editors and Viewers
- Replies (21)
|
|
Hi,
thanks to Travis' help my batch pov generation script works fine.
But, I encountered several issues when rendering some parts.
for exemple :
Code: "d:\lego\python\data\renders\0\14639p01.pov" line 1117: Parse Error: Expected 'object', undeclared identifier 'LDX_1_dash_16ring9_dot_dat_in_part' found instead
Render failed
First of all, and obviously, the primitive is in my "ldraw\p\" directory, andthe 14639p01dat part opens without errors in LDview.
Then, I thought that some config file like LGEO.xml or LGDefs.inc were involved, but they do not have anything to do with that (if I'm right).
So I took a look at the buggy files and the integration of primitives in pov files.
If I understand the error message correctly, LDX_1_dash_16ring9_dot_dat_in_part has not been defined before, not like the other primitives involved in that part.
So, at some point, some lines like those for 1-16ri60.dat :
Code: #declare LDX_48_slash_1_dash_16ri60_dot_dat_in_part = disc // Ring 0.0625
{
<0,0,0>,<0,1,0>,61,60
clipped_by
{
plane
{
<0,0,-1>,0
}
plane
{
<-0.38268343236508972627,0,0.92387953251128673848>,0
}
}
}
#declare LDX_48_slash_1_dash_16ri60_dot_dat = disc // Ring 0.0625
{
<0,0,0>,<0,1,0>,61,60
clipped_by
{
plane
{
<0,0,-1>,0
}
plane
{
<-0.38268343236508972627,0,0.92387953251128673848>,0
}
}
}
should have been written in the pov file but aren't. And I suppose that I can't choose randoms coordinates to solve the problem.
So my question is : do the problem come from a config file I didn't think about, or is it a export bug ?
I've the problem with other primitives on other parts.
|
|
|
|
SEC(MOC) from clone brand |
|
Posted by: Jaco van der Molen - 2021-03-16, 15:18 - Forum: MOCs (My Own Creations)
- Replies (2)
|
 |
Hi all,
Long had I had doubts to post this, but here goes...
I stumbled upon some, I almost dear not say, very nice models from a certain clone brand.
Now I am translating those digitally to LEGO versions.
Since this clone brand uses some parts LEGO does not have* or in colors that do not exist in LEGO, I am kind of redesigning the models and re-coloring them.
Would it be allowed to post these models here? Or is that a no-go and not done?
I plan to make the models as close to the original ones (thus using colors that do not exist in LEGO and some very dirty mockup non-LEGO parts) and then a pure and buildable LEGO version
Since certain clone brands do the same with LEGO and often ruthlessly make exact copies of LEGO sets or even steal ideas from people who post MOCs to communities and even LEGO Ideas, I thought of doing the same. Or could I get into trouble in doing so? Then I'll keep the models to myself.
Thoughts?
*P.S. ...but would be nice if LEGO makes these parts... ;-)
For example a 1x1 panel (not the cornered one), plate 1x5, inverted plate, or 1x2 plate with studs on both sides... etc.
|
|
|
|
|
![[Image: 3068bpb1126.png]](https://img.bricklink.com/ItemImage/PN/1/3068bpb1126.png)
