| |
Are there any tools that allow you to manipulate a minifig AFTER you place it
into a file? I realize that MLCad has a minifig generator, which is fantastic,
but once you place the fig, to produce another pose, you need to generate a new
fig from scratch...
Anyone have any suggestions?
-Andy Lynch
|
|
| |
In lugnet.cad, Andy Lynch wrote:
> Are there any tools that allow you to manipulate a minifig AFTER you place it
> into a file? I realize that MLCad has a minifig generator, which is fantastic,
> but once you place the fig, to produce another pose, you need to generate a new
> fig from scratch...
>
> Anyone have any suggestions?
I haven't used the minifig feature, but it looks like SR 3D Builder
(http://staff.polito.it/sergio.reano/) has a pretty nice minifig poser (see
around 2:00 in for editing of existing pose):
http://www.youtube.com/profile?user=xSergio74#p/u/2/B3icB3f1yac
Jim
|
|
| |
In lugnet.cad, Andy Lynch wrote:
> Are there any tools that allow you to manipulate a minifig AFTER you place it
> into a file? I realize that MLCad has a minifig generator, which is fantastic,
> but once you place the fig, to produce another pose, you need to generate a new
> fig from scratch...
>
> Anyone have any suggestions?
>
> -Andy Lynch
I always insert minifigs as submodels for this reason. I also wish I could
insert them as MLCad-Part like the spring.
cu
mikeheide
|
|
| |
In lugnet.cad, Michael Heidemann wrote:
> In lugnet.cad, Andy Lynch wrote:
> > Are there any tools that allow you to manipulate a minifig AFTER you place it
> > into a file? I realize that MLCad has a minifig generator, which is fantastic,
> > but once you place the fig, to produce another pose, you need to generate a new
> > fig from scratch...
> >
> > Anyone have any suggestions?
> >
> > -Andy Lynch
>
> I always insert minifigs as submodels for this reason. I also wish I could
> insert them as MLCad-Part like the spring.
>
> cu
> mikeheide
I think it would be relatively easy ro create a program that:
* Opens an LCad model file
* Uses MLCad.ini or something in its likeness to scan for and identify minifig
parts
* Extracts a minifig into a new file
* Writes a reference to the new file in the original model file
* Writes undo information in the original model file
* Scan for next minifig or quit
The reference to the minifig should be made so that the hips part is @
0 0 0 1 0 0 0 1 0 0 0 1
in the minifig model file for easier manipulation.
The manipulator could be in the same program or a separate (maybe an already
existing?) app.
I don't think I have what it takes anymore to make such a program, but it would
surprise me if this is any challange for any other LCad programmer?
/Tore
|
|
| |
In lugnet.cad, Andy Lynch wrote:
> Are there any tools that allow you to manipulate a minifig AFTER you place it
> into a file? I realize that MLCad has a minifig generator, which is fantastic,
> but once you place the fig, to produce another pose, you need to generate a new
> fig from scratch...
>
> Anyone have any suggestions?
>
> -Andy Lynch
Hi,
LD4DStudio can export to ldr file(s), which you can refer to in your main ldr.
Roland
|
|
| |
In lugnet.cad, Tore Eriksson wrote:
> The reference to the minifig should be made so that the hips part is @
> 0 0 0 1 0 0 0 1 0 0 0 1
> in the minifig model file for easier manipulation.
No. Absolutely not. For this to be worthwhile, the original positional and
rotational data should be retained when extracting the minifig. Consider what
would happen if you are extracting a minifig whose hips are not oriented at
right angles, like one that's in a reclined seating position. It would be
tilted at an angle, and the reference point data would be fractional in at least
two dimensions. Basically what that means is that it would be practically
impossible to ever reposition the minifig back where it came from.
To be useful for manipulating placed minifigs, it needs to be able to handle
having the torso/hips in a non-vertical plane, and it needs to be able to rotate
the upper body in relation to the legs in addition to being able to rotate the
legs around the rest of the body (which the current MLCad minifig generator is
incapable of doing). Most importantly, though, is that if this is supposed to
be a better alternative to simply keeping track of the numbers you used and
doing trial-and-error processing with the minifig generator, it needs to be able
to put the minifig back exactly where it came from (aside from any changes you
made to the positioning).
|
|
| |
In lugnet.cad, David Laswell wrote:
> In lugnet.cad, Tore Eriksson wrote:
> > The reference to the minifig should be made so that the hips part is @
> > 0 0 0 1 0 0 0 1 0 0 0 1
> > in the minifig model file for easier manipulation.
>
> No. Absolutely not. For this to be worthwhile, the original positional and
> rotational data should be retained when extracting the minifig. Consider what
> would happen if you are extracting a minifig whose hips are not oriented at
> right angles, like one that's in a reclined seating position. It would be
> tilted at an angle, and the reference point data would be fractional in at least
> two dimensions. Basically what that means is that it would be practically
> impossible to ever reposition the minifig back where it came from.
>
> To be useful for manipulating placed minifigs, it needs to be able to handle
> having the torso/hips in a non-vertical plane, and it needs to be able to rotate
> the upper body in relation to the legs in addition to being able to rotate the
> legs around the rest of the body (which the current MLCad minifig generator is
> incapable of doing). Most importantly, though, is that if this is supposed to
> be a better alternative to simply keeping track of the numbers you used and
> doing trial-and-error processing with the minifig generator, it needs to be able
> to put the minifig back exactly where it came from (aside from any changes you
> made to the positioning).
Hmm. I guess you're right. If so, even my LDA is incapable of animate tilting of
the minifigs. Got to check that out.
How would you suggest the reference to a minifig should look like from its
mother objest?
/Tore
|
|
| |
In lugnet.cad, David Laswell wrote:
> In lugnet.cad, Tore Eriksson wrote:
> > The reference to the minifig should be made so that the hips part is @
> >
> > in the minifig model file for easier manipulation.
> To be useful for manipulating placed minifigs, it needs to be able to handle
> having the torso/hips in a non-vertical plane, and it needs to be able to rotate
> the upper body in relation to the legs in addition to being able to rotate the
> legs around the rest of the body (which the current MLCad minifig generator is
> incapable of doing). Most importantly, though, is that if this is supposed to
> be a better alternative to simply keeping track of the numbers you used and
> doing trial-and-error processing with the minifig generator, it needs to be able
> to put the minifig back exactly where it came from (aside from any changes you
> made to the positioning).
I think my minifig generator for LDDP might be able to be modified to do this.
I'll look into it.
-Orion
|
|
| |
In lugnet.cad, Jim DeVona wrote:
> I haven't used the minifig feature, but it looks like SR 3D Builder
> (http://staff.polito.it/sergio.reano/) has a pretty nice minifig poser (see
> around 2:00 in for editing of existing pose):
>
> http://www.youtube.com/profile?user=xSergio74#p/u/2/B3icB3f1yac
>
> Jim
Wow. I hadn't seen that tool before. I didn't get to try out the minifig poser
yet, but the connection and rotation features make it something that I'm really
going to look into. Thanks!
-Andy
|
|
| |
On 1/9/2010 3:49 PM, Orion Pobursky wrote:
> I think my minifig generator for LDDP might be able to be modified to do this.
> I'll look into it.
>
> -Orion
Of course the problem with this approach is that you have to learn Yet
Another ApplicationTM to do what you want.
--
--
Michael Horvath
mikh2161@gmail.com
http://isometricland.com
|
|
| |
In lugnet.cad, Michael Horvath wrote:
> On 1/9/2010 3:49 PM, Orion Pobursky wrote:
> > I think my minifig generator for LDDP might be able to be modified
> > to do this. I'll look into it.
>
> Of course the problem with this approach is that you have to learn Yet
> Another ApplicationTM to do what you want.
So how about this time we do something universal? We've talked this up
before at least once:
http://news.lugnet.com/cad/?n=11517
Who wants to step forward and propose some generic META commands to
at least identify a group of parts that belong to a single minifig?
Can we adapt the existing MLCAD group meta command for this by requiring
the word MINIFIG as the first part of the group name? Something like this:
0 GROUP 8 MINIFIG OctanMan
0 MLCAD BTG MINIFIG OctanMan
1 ... left leg
Is that agreeable? Or would it be better to start from scratch?
Don
|
|
| |
In lugnet.cad, Don Heyse wrote:
> In lugnet.cad, Michael Horvath wrote:
> > On 1/9/2010 3:49 PM, Orion Pobursky wrote:
> > > I think my minifig generator for LDDP might be able to be modified
> > > to do this. I'll look into it.
> >
> > Of course the problem with this approach is that you have to learn Yet
> > Another ApplicationTM to do what you want.
>
> So how about this time we do something universal? We've talked this up
> before at least once:
>
> http://news.lugnet.com/cad/?n=11517
>
> Who wants to step forward and propose some generic META commands to
> at least identify a group of parts that belong to a single minifig?
> Can we adapt the existing MLCAD group meta command for this by requiring
> the word MINIFIG as the first part of the group name? Something like this:
>
> 0 GROUP 8 MINIFIG OctanMan
> 0 MLCAD BTG MINIFIG OctanMan
> 1 ... left leg
>
> Is that agreeable? Or would it be better to start from scratch?
I support extending the language. Maybe not in the above form but in some form.
I'd also love to see something like the MLCad.ini minifig entries standardized.
It doesn't have to be officially supported, a de facto standard is still a
standard.
-Orion
|
|
| |
In lugnet.cad, Orion Pobursky wrote:
> In lugnet.cad, Don Heyse wrote:
> > In lugnet.cad, Michael Horvath wrote:
> > > On 1/9/2010 3:49 PM, Orion Pobursky wrote:
> > > > I think my minifig generator for LDDP might be able to be modified
> > > > to do this. I'll look into it.
> > >
> > > Of course the problem with this approach is that you have to learn Yet
> > > Another ApplicationTM to do what you want.
> >
> > So how about this time we do something universal? We've talked this up
> > before at least once:
> >
> > http://news.lugnet.com/cad/?n=11517
> >
> > Who wants to step forward and propose some generic META commands to
> > at least identify a group of parts that belong to a single minifig?
> > Can we adapt the existing MLCAD group meta command for this by requiring
> > the word MINIFIG as the first part of the group name? Something like this:
> >
> > 0 GROUP 8 MINIFIG OctanMan
> > 0 MLCAD BTG MINIFIG OctanMan
> > 1 ... left leg
> >
> > Is that agreeable? Or would it be better to start from scratch?
>
> I support extending the language. Maybe not in the above form but in some form.
> I'd also love to see something like the MLCad.ini minifig entries standardized.
> It doesn't have to be officially supported, a de facto standard is still a
> standard.
>
> -Orion
Me too. I would prefer if we could set a standard within existing META-command
sets, but I doubt that it may meet our requirements.
Btw, what are our requirements? What do we want achieve?
I could think of:
1. Standard tags that indicate...
1a. MINIFIG object starts here (and an end tag is probably desirable, too)
1b. MINIFIG part or accessory
2. The possibilities to both manipulate the minifig either within the model (as
a "GROUP"???) or extract minifig into a new single minifig sub-model.
3. A "connections database" to aid the various minifig manipulators (be it
plug-in, built-in features or stand-alone utilities; all kinds should be able to
find the information needed in one file). Unfortunately, it looks like MLCad.ini
doesn't provide sufficient data for this right now. Maybe LDConfig.ldr would be
the appropriate place to host this information? Who says that it should only
contain colour data? Or, I have just a very vauge idea of how the ROTATION
CENTER and CONFIG metacommands work, but maybe they can do that work? I suspect
not, but I just brainstorm a little.
- - -
Maybe we should leave the syntax door open for other figures than standard
minifigs (hey, why limit it to figures at all...?) - but then again, the work to
set such a standard would probably take almost forever. :)
What if we all work on a proof of concept and then leave to the LSC to set an
exact official syntax standard when someone has come up with a working concept?
/Tore
|
|
| |
In lugnet.cad, Tore Eriksson wrote:
> In lugnet.cad, Orion Pobursky wrote:
> > In lugnet.cad, Don Heyse wrote:
> > > In lugnet.cad, Michael Horvath wrote:
> > > > On 1/9/2010 3:49 PM, Orion Pobursky wrote:
> > > > > I think my minifig generator for LDDP might be able to be modified
> > > > > to do this. I'll look into it.
> > > >
> > > > Of course the problem with this approach is that you have to learn Yet
> > > > Another ApplicationTM to do what you want.
> > >
> > > So how about this time we do something universal? We've talked this up
> > > before at least once:
> > >
> > > http://news.lugnet.com/cad/?n=11517
> > >
> > > Who wants to step forward and propose some generic META commands to
> > > at least identify a group of parts that belong to a single minifig?
> > > Can we adapt the existing MLCAD group meta command for this by requiring
> > > the word MINIFIG as the first part of the group name? Something like this:
> > >
> > > 0 GROUP 8 MINIFIG OctanMan
> > > 0 MLCAD BTG MINIFIG OctanMan
> > > 1 ... left leg
> > >
> > > Is that agreeable? Or would it be better to start from scratch?
> >
> > I support extending the language. Maybe not in the above form but in some form.
> > I'd also love to see something like the MLCad.ini minifig entries standardized.
> > It doesn't have to be officially supported, a de facto standard is still a
> > standard.
> >
> > -Orion
>
> Me too. I would prefer if we could set a standard within existing META-command
> sets, but I doubt that it may meet our requirements.
>
> Btw, what are our requirements? What do we want achieve?
> I could think of:
> 1. Standard tags that indicate...
> 1a. MINIFIG object starts here (and an end tag is probably desirable, too)
> 1b. MINIFIG part or accessory
> 2. The possibilities to both manipulate the minifig either within the model (as
> a "GROUP"???) or extract minifig into a new single minifig sub-model.
> 3. A "connections database" to aid the various minifig manipulators (be it
> plug-in, built-in features or stand-alone utilities; all kinds should be able to
> find the information needed in one file). Unfortunately, it looks like MLCad.ini
> doesn't provide sufficient data for this right now. Maybe LDConfig.ldr would be
> the appropriate place to host this information? Who says that it should only
> contain colour data? Or, I have just a very vauge idea of how the ROTATION
> CENTER and CONFIG metacommands work, but maybe they can do that work? I suspect
> not, but I just brainstorm a little.
Here is what I have found out about that META commands:
0 ROTATION CENTER 0 0 0 1 "Custom1"
0 ROTATION CENTER 2 3 4 1 "New Custom"
The first three numbers are the xyz values of the rotation point
The fourth number indicates the "Allow on-screen change"
The string at the end is the name of that rotation point.
0 ROTATION CONFIG 1 0
The first number indicates the current aktive point from above list.
The second number indicates "Show rotation point"
As this value is used for the complete model it can not be of any help with our
current problem IMHO.
cu
mikeheide
|
|
| |
In lugnet.cad, Tore Eriksson wrote:
> 3. A "connections database" to aid the various minifig manipulators (be it
> plug-in, built-in features or stand-alone utilities; all kinds should be able to
> find the information needed in one file). Unfortunately, it looks like MLCad.ini
> doesn't provide sufficient data for this right now. Maybe LDConfig.ldr would be
> the appropriate place to host this information? Who says that it should only
> contain colour data?
Of course: LDraw.ini could host such information in a new section! No risk to
violate any existing standard, no need to create yet another file to look for!
/Tore
|
|
| |
In lugnet.cad, Tore Eriksson wrote:
> In lugnet.cad, Tore Eriksson wrote:
> > 3. A "connections database" to aid the various minifig manipulators (be it
> > plug-in, built-in features or stand-alone utilities; all kinds should be able to
> > find the information needed in one file). Unfortunately, it looks like MLCad.ini
> > doesn't provide sufficient data for this right now. Maybe LDConfig.ldr would be
> > the appropriate place to host this information? Who says that it should only
> > contain colour data?
>
> Of course: LDraw.ini could host such information in a new section! No risk to
> violate any existing standard, no need to create yet another file to look for!
>
> /Tore
I agree but we still need to standardize where the LDraw.ini will be for each
OS. This location has to read/write accessible. My suggestions for the OSs I
use are:
Windows: $APPDATA\LDraw
OSX: $HOME/Library/LDraw
-Orion
|
|
|
