| |
In lugnet.cad.dev, Larry Pieniazek writes:
> In lugnet.cad.dev, Kevin L. Clague writes:
> > In lugnet.cad.dev, Larry Pieniazek writes:
>
> > > Except for time/skill/interest. (mostly time)
> >
> > I assume the lack of interest is in the coding, not the using :^)
>
> Ya. I have made good use of LSynth for hoses and for rubber bands in my
> current project and found it easy to use so I'm definitely interested in
> using it!!!!
>
> > I have a similar lack of time.
>
> OK, well maybe you've shamed me into taking a look. I just went to sourceforge
> (http://sourceforge.net/projects/lsynth/) but I'm not seeing the code there.
> Am I looking in the wrong place? Not saying I'll GET any time to look at
> this anytime soon, mind you.
I found the code (I was looking for released files, not in the CVS tree) and
have extracted it (via WinCVS) to take a look...
|
|
| |
In lugnet.cad.dev, Larry Pieniazek writes:
> I found the code (I was looking for released files, not in the CVS tree) and
> have extracted it (via WinCVS) to take a look...
OK, I did a little digging. If I understand what I am reading, the various
types of things that can be synthesized are defined with constants in the
lsynth.h include.
Elsewhere in the code these constants are checked (driven by what's found in
the .dat file being processed) to determine various things. For example the
function calc_angles in band.c uses these constants to determine angles of
things (based on the constraint that's being rounded)... this sort of
decision making appears in a number of places, but the numbers used depend
on the type of the thing being synthesized.
If I'm reading things right, to hack another type of synthesized thing in
would mean merely finding all the places where these constants are evaluated
and adding an additional elseif to honor the new type (depending on if it
was band or tube).
All that needs to be done (for string) to do that is decide what a good
element to represent a string segment is, and what the basic geometry of it
is (x,y,z dimensions).
But I don't HAVE a good element! The one I use is crappy, it's just an
approximation and just something I hacked up quickly. If committment to that
element is made, we all would regret it later. Better to allow that we swap
out definitions once someone does a better job of modeling string than I
did. The dimensions of a better string element may vary significantly from
the dimensions I chose... (because modeling the triplestrandedness may
require it to be smaller! or larger if you think about how one element has
to abut the next... unless the element includes 120 degrees of string
rotation you also have to handle rotating each instance of the element by
the right amount)
So the better way to do this would be to let the element itself be
parameterized, that is, supply the element definition (it's dimensions and
desired rotational orientation) in an external file. I suspect that adding
that functionality is quite a bit harder as it's not merely hacking in new
constants in a new elseif block, but actually changing the program to get
parms from an external file for some (or all?? that would allow other
elements to be improved if there ever was a need) element types...
That seems pretty hard to me, at this juncture, given that I haven't coded
in C in years (although one never forgets, it's like riding a bicycle). But
not undoable.
On that note, I've installed MinGW to give me gcc (because I see the
makefule specs gcc as the compiler)... but it didn't come with a make...
what's a good recommendation for a make? make-3.79.1 ?? Would I need MSys
too? (win 2k platform)
|
|
| |
"Larry Pieniazek" <lpieniazek@mercator.com> wrote in message
news:HDrH7u.1FKp@lugnet.com...
[ ... snipped ... ]
>
> On that note, I've installed MinGW to give me gcc (because I see the
> makefule specs gcc as the compiler)... but it didn't come with a make...
> what's a good recommendation for a make? make-3.79.1 ?? Would I need MSys
> too? (win 2k platform)
You can get a full complemnt of Unix utilities for your PC (including Make)
by installing Cygwin (which is free): http://www.cygwin.com It has a hokey
install process but it works well once installed.
Mike
--
Mike Walsh - mike_walsh at mindspring.com
http://www.ncltc.cc - North Carolina LEGO Train Club
http://www.carolinatrainbuilders.com - Carolina Train Builders
http://www.bricklink.com/store.asp?p=mpw - CTB/Brick Depot
|
|
| |
In lugnet.cad.dev, Larry Pieniazek writes:
> In lugnet.cad.dev, Larry Pieniazek writes:
>
> > I found the code (I was looking for released files, not in the CVS tree) and
> > have extracted it (via WinCVS) to take a look...
>
> OK, I did a little digging. If I understand what I am reading, the various
> types of things that can be synthesized are defined with constants in the
> lsynth.h include.
>
> Elsewhere in the code these constants are checked (driven by what's found in
> the .dat file being processed) to determine various things. For example the
> function calc_angles in band.c uses these constants to determine angles of
> things (based on the constraint that's being rounded)... this sort of
> decision making appears in a number of places, but the numbers used depend
> on the type of the thing being synthesized.
You read undocumented code quite well!
>
> If I'm reading things right, to hack another type of synthesized thing in
> would mean merely finding all the places where these constants are evaluated
> and adding an additional elseif to honor the new type (depending on if it
> was band or tube).
Yup. But unfortunatly you want to combine open things (tubes) with closed
loops (bands), and the program is fundamentally *not* written for that.
Bummer.
>
> All that needs to be done (for string) to do that is decide what a good
> element to represent a string segment is, and what the basic geometry of it
> is (x,y,z dimensions).
>
> But I don't HAVE a good element! The one I use is crappy, it's just an
> approximation and just something I hacked up quickly. If committment to that
> element is made, we all would regret it later. Better to allow that we swap
> out definitions once someone does a better job of modeling string than I
> did. The dimensions of a better string element may vary significantly from
> the dimensions I chose... (because modeling the triplestrandedness may
> require it to be smaller! or larger if you think about how one element has
> to abut the next... unless the element includes 120 degrees of string
> rotation you also have to handle rotating each instance of the element by
> the right amount)
Will the element do for now? Maybe we can enhance it later. As the part
author, you have the right to change it later.
>
> So the better way to do this would be to let the element itself be
> parameterized, that is, supply the element definition (it's dimensions and
> desired rotational orientation) in an external file. I suspect that adding
> that functionality is quite a bit harder as it's not merely hacking in new
> constants in a new elseif block, but actually changing the program to get
> parms from an external file for some (or all?? that would allow other
> elements to be improved if there ever was a need) element types...
>
> That seems pretty hard to me, at this juncture, given that I haven't coded
> in C in years (although one never forgets, it's like riding a bicycle). But
> not undoable.
Then your generic approach is the wrong one for you. Why not just hard code
what you want now in your own private copy (as a make shift tube I guess), and
do with it what you will.
I plan on whacking on LSynth pretty hard after I get to a good pausing point in
LPub. I'm a good candidate for adding what you want.
In the mean time, you can have what you want (sort of.)
>
> On that note, I've installed MinGW to give me gcc (because I see the
> makefule specs gcc as the compiler)... but it didn't come with a make...
> what's a good recommendation for a make? make-3.79.1 ?? Would I need MSys
> too? (win 2k platform)
Kevin
|
|
| |
In lugnet.cad.dev, Mike Walsh writes:
>
> "Larry Pieniazek" <lpieniazek@mercator.com> wrote in message
> news:HDrH7u.1FKp@lugnet.com...
>
> [ ... snipped ... ]
>
> >
> > On that note, I've installed MinGW to give me gcc (because I see the
> > makefule specs gcc as the compiler)... but it didn't come with a make...
> > what's a good recommendation for a make? make-3.79.1 ?? Would I need MSys
> > too? (win 2k platform)
>
> You can get a full complemnt of Unix utilities for your PC (including Make)
> by installing Cygwin (which is free): http://www.cygwin.com It has a hokey
> install process but it works well once installed.
Thanks Mike.
Meanwhile I just installed make-3.79.1 and it makes lsynthcp OK without
needing to install MSys. Gotta think about whether I want Cygwin or not...
it's not like I don't have a bazillion other things I should be working on
instead. :-)
|
|
| |
In lugnet.cad.dev, Kevin L. Clague writes:
> Yup. But unfortunatly you want to combine open things (tubes) with closed
> loops (bands), and the program is fundamentally *not* written for that.
> Bummer.
Not to worry, combining things is more of a stretch goal (if you'll pardon
the pun). Just one is good enough for now.
> Then your generic approach is the wrong one for you. Why not just hard code
> what you want now in your own private copy (as a make shift tube I guess), and
> do with it what you will.
Maybe that's the way to go. I think actually I would go with Band and then
hand edit away the 1/2 (of the synthesized elements generated) that wasn't
needed because in most of my string uses, the string is taut.
> I plan on whacking on LSynth pretty hard after I get to a good pausing
> point in LPub. I'm a good candidate for adding what you want.
Let me think more on requirements for specifying elements to be used in
synthesis generically, then. At first blush I think the key things are:
- x,y,z dimensions of the element (with one axis assumed to be the
centerline axis, either always by convention or you have to specify which
axis it is)
- center point of the element (to allow for non symmetric elements)
- Do successive usages of the element have to be mirrored (or placed back to
back)? (my string does)
- Do successive usages of the element have to be rotated around the
centerline of the element and if so, by how much (a high fidelity string
element that properly models triplestrandedness but is short enough to
conform to small radius things may well need to do so as it will be too
short for 120 degrees worth of strand being within the element)
any others?
|
|
|
