| Welcome, Guest |
You have to register before you can post on our site.
|
|
|
| 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.
|
|
|
|
| Search path discussion |
|
Posted by: Orion Pobursky - 2021-03-16, 13:26 - Forum: Official File Specifications/Standards
- Replies (49)
|
 |
Since non-LSB members can't comment on the LSB forum, this thread is for discussion of the search path proposal there.
To kick this off I'd like to comment on something Roland posted:
Quote:I disagree on this, a stud.dat should not replace all studs in the whole scene if it's located in the mpd itself or its folder.
This is precisely the point of embedding such a file in the MPD and why we do it for the OMR. Local files should always override library parts. Otherwise the OMR breaks and parts authoring become morse inconvenient since you'd have to overwrite the official file if you're using or creating a fix.
|
|
|
|
| 87552.dat or 94638.dat? ..... in set 10295 - Porsche. |
|
Posted by: Ulrich Röder - 2021-03-15, 14:18 - Forum: Parts Authoring
- Replies (4)
|
 |
87552.dat or 94638.dat?
..... in set 10295 - Porsche.
https://rebrickable.com/media/parts/phot...b097ea.jpg
Quote:
0 = panel 1 x 2 x 2 reinforced
0 Name: 94638.dat
0 Author: J.C. Tchang [tchang]
0! LDRAW_ORG Part Alias UPDATE 2020-01
0! LICENSE Redistributable under CCAL version 2.0: see CAreadme.txt
0! HELP Part 94638 is the counterpart of 87552. Visually, the two parts seem
0! HELP identical. This file is provided to make it easier to locate part files
0! HELP when using the numbers from other sources.
0! HELP 87552 is used for molding opaque parts, 94638 for transparent parts.
*
Regardless of where you get information - 87552 is always used in the name.
*
87552 is used for molding opaque parts ...
94638 for transparent parts ....
Is this correct?
*
Since there are no printed parts of it yet:
Which end identifier ("........ p01.dat"?)
.... can someone please clarify.
|
|
|
|
| Animation puzzle |
|
Posted by: Walt White - 2021-03-15, 0:15 - Forum: LDraw Editors and Viewers
- Replies (1)
|
 |
animationDemo.ldr (Size: 1.35 KB / Downloads: 1)
I'm using LDCad 1.6d, working on an animation, and have a baffling problem. I can recreate the problem using Roland's original basic animation demo on YouTube:
I create the model and copy his LUA script. See aniDemoModel.png
As soon as I launch the LUA script, the Axle1 sub-model jumps to a new position on the first frame. It also loses the 13° rotation that allowed its 14 tooth gear to mesh correctly with the Axle2 gear. See aniDemoMove.png
Then using Roland's setRotate(angle, 1, 0, 0) the sub-model rotates around the wrong axis. See aniDemoWrongAxis.png
Changing setRotate() to "angle, 0, 0, 1" fixes the wrong axis problem so the sub-model rotates around the correct axis, but I can't find any way to keep the sub-model from jumping to the new position and losing its 13° adjustment.
I've done other animations (which still work) and have never seen this problem. Now it's happening to every new model I make!
Model:
![[Image: aniDemoModel.png]](https://www.bricksafe.com/files/Walt.White/animation-demo/aniDemoModel.png)
Move:
![[Image: aniDemoMove.png]](https://www.bricksafe.com/files/Walt.White/animation-demo/aniDemoMove.png)
Wrong axis:
![[Image: aniDemoWrongAxis.png]](https://www.bricksafe.com/files/Walt.White/animation-demo/aniDemoWrongAxis.png)
LDR file:
Code: 0 FILE main.ldr
0 Name: animationDemo
0 Author: LDCad
0 !LDCAD SCRIPT [source=animationDemo.lua]
1 14 0 0 0 1 0 0 0 1 0 0 0 1 3702.dat
1 14 50 0 -30 0 0 1 0 1 0 -1 0 0 3700.dat
1 14 -70 0 -30 0 0 1 0 1 0 -1 0 0 3700.dat
1 14 -10 0 -30 0 0 1 0 1 0 -1 0 0 3700.dat
1 14 0 0 -60 1 0 0 0 1 0 0 0 1 3702.dat
1 14 -70 -8 -30 0 0 1 0 1 0 -1 0 0 3710.dat
1 14 -10 -8 -30 0 0 1 0 1 0 -1 0 0 3710.dat
1 14 50 -8 -30 0 0 1 0 1 0 -1 0 0 3710.dat
1 14 50 24 -30 0 0 1 0 1 0 -1 0 0 3710.dat
1 14 -10 24 -30 0 0 1 0 1 0 -1 0 0 3710.dat
1 14 -70 24 -30 0 0 1 0 1 0 -1 0 0 3710.dat
1 16 -23 10 -30 0 0 1 0 1 0 -1 0 0 Axle2.ldr
1 14 50 -16 -30 0 0 1 0 1 0 -1 0 0 3023.dat
1 14 50 -40 -30 0 0 1 0 1 0 -1 0 0 3700.dat
1 16 60 -30 -30 1 0 0 0 0.99 0.139 0 -0.139 0.99 Axle3.ldr
1 16 -40 10 -80 -0.974 -0.225 0 -0.225 0.974 0 0 0 -1 Axle1.ldr
0 FILE Axle1.ldr
0 Author: LDraw
1 71 0 0 0 1 0 0 0 1 0 0 0 1 3736.dat
1 0 0 0 -50 0 0 -1 0 1 0 1 0 0 3706.dat
1 71 0 0 -67 -1 0 0 0 1 0 0 0 -1 4143.dat
1 71 0 0 -99.997 1 0.001 0 -0.001 1 0 0 0 1 3713.dat
1 71 -30 0 12 0 0.139 -0.99 0 0.99 0.139 1 0 0 3749.dat
0 FILE Axle2.ldr
0 Author: LDraw
1 71 0 0 0 1 0 0 0 1 0 0 0 1 4143.dat
1 0 0 0 53 0 0 1 0 1 0 -1 0 0 3706.dat
1 71 0 0 93 1 0 0 0 1 0 0 0 1 3647.dat
0 FILE Axle3.ldr
0 Author: LDraw
1 71 0 0 0 1 0 0 0 1 0 0 0 1 3749.dat
1 71 10 0 0 0 0 1 0 1 0 -1 0 0 3648.dat
LUA code:
Code: function register()
local ani=ldc.animation('animationDemo')
ani:setLength(20)
ani:setEvent('frame', 'onFrame')
end
function onFrame()
local ani=ldc.animation.getCurrent()
local mainSf=ldc.subfile()
local ori=ldc.matrix()
local angle=720*ani:getFrameTime()/ani:getLength()
local ax1=mainSf:getRef('Axle1.ldr')
ori:setRotate(angle, 0, 0, 1)
ax1:setOri(ori)
end
register()
|
|
|
|
| Standardize official search path |
|
Posted by: Travis Cobbs - 2021-03-14, 1:50 - Forum: Standards Board
- Replies (15)
|
 |
It has been requested that we standardize the official search path. So I'm creating this thread to do that. Right now, I think that most programs follow in LDView's footsteps, but I'm open for the official search path being different. LDView by default looks for files in the following order:
MPD subfiles
Model Directory (the directory that the top-level model resides in)
<LDraw>\p
<LDraw>\parts
<LDraw>\models
<LDraw>\Unofficial\p
<LDraw>\Unofficial\parts
If we agree that the above order is correct, we can then discuss where to put it in the specification. If we want a different default search path, we can discuss that.
Note: If your name isn't Travis Cobbs, Chris Dee, or Roland Melkert, please don't respond to this thread. Read the rules for this board. Other than the three of us, only admins and mods can post here, but they aren't supposed to do so. If you want to bring up concerns, do so in the Parts Authoring board.
|
|
|
|
|
