 | | | | | |
Looking for some form of Documenation, on MAKING not using Primitives.
Prefer something that does not require a BS in math to understand.
Anyone have anything they can point me to?
Thanks,
Dwayne Miller
Barberton, Ohio USA
| | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dat.parts, Dwayne Miller writes:
> Looking for some form of Documenation, on MAKING not using Primitives.
> Prefer something that does not require a BS in math to understand.
>
> Anyone have anything they can point me to?
>
> Thanks,
> Dwayne Miller
> Barberton, Ohio USA
In principle, making primitives is no different to making parts, you just need
to think a little more about the generalities of what you are making and ensure
the reusability factor is high enough. We are also insisting that all new
primitives are BFC compliant.
To quote the Primitives Reference, the primary purpose of primitives is
* To speed up parts authoring by providing a library of components which can
be incorporated into several parts
* To allow rendering software to make substitutions of curved components
In terms of the existing _classes_ of primitives, I think we're pretty well
covered - either we have most of the variants we need, or have the tools to
produce the missing ones when we need them.
So, I'm intrigued as to where you think the LDraw library could benefit from
more primitives.
I'm happy for this discussion to happen here, or take off line with Steve Bliss
and myself at parts@ldraw.org. In any case, if you have ideas for new _classes_
off primtives, we would want to be involved in the nomenclature.
Chris
| | | | | | | | | | | | | | | | | |
| |
|
> > Looking for some form of Documenation, on MAKING not using Primitives.
> > Prefer something that does not require a BS in math to understand.
> >
> > Anyone have anything they can point me to?
> In principle, making primitives is no different to making parts, you just need
> to think a little more about the generalities of what you are making and ensure
> the reusability factor is high enough. We are also insisting that all new
> primitives are BFC compliant.
BFC, thats something I have not even considered... hmm... will understand more
when I explain more later in this reply.
>
> To quote the Primitives Reference, the primary purpose of primitives is
> * To speed up parts authoring by providing a library of components which can
> be incorporated into several parts
> * To allow rendering software to make substitutions of curved components
>
> In terms of the existing _classes_ of primitives, I think we're pretty well
> covered - either we have most of the variants we need, or have the tools to
> produce the missing ones when we need them.
Very true, for Lego based parts, I agree. I doubt I could even with 10 years of
thinking come up with another primitve that would really contribute to the
project.
> So, I'm intrigued as to where you think the LDraw library could benefit from
> more primitives.
The LDraw Library for Lego Parts, nope, but as I am not making LDraw Parts for
Legos, loads. Working with something similar to Legos (see my recent posts on
l.d.c Question on the Future of LDraw family ) but not at all compatible. (IE
they are not a lego clone or any such thing.)
There are tons of parts that need made and making some primitives for such
parts would really help speed stuff up.
Now, what are these blocks? See http://www.hirstarts.com. I have been in
contact with Tim Courtney on this matter, and he has encouraged me to go forth
with this effort, and to ask questions here, (BTW, I totally missed the
l.c.d.parts.primitives group, or would have posted it there) on the newsserver,
and to see if anyone here might be interested in helping with such a project.
> I'm happy for this discussion to happen here, or take off line with Steve Bliss
> and myself at parts@ldraw.org. In any case, if you have ideas for new _classes_
> off primtives, we would want to be involved in the nomenclature.
I would welcome your help, and would be more than willing to discuss this off
list, if that would be better, but a little exposure for this project is partly
the reason for my question.
Also, even tho most of the needed primitives are written, would not having docs
on writing said primitves be a wise thing to have around anyway. Would not hurt
to have them, for future generations, at least. Who knows what Lego will decide
to put out for parts in 30 years. Then again, thats just my opinion. Your
milage may vary.
> Chris
Thanks for your reply,
Dwayne
Barberton, Ohio USA
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dat.parts, Dwayne Miller writes:
> > > Looking for some form of Documenation, on MAKING not using Primitives.
> > > Prefer something that does not require a BS in math to understand.
Hi again Dwayne,
I am a bit out on a limb here, but it seems what you are missing in the
picture is an understanding of *rotation matrices*. These are indeed a magic
key, but are not easy to grasp - at least that is the case with me. I've
only learned about them recently - thanks to Kevin Clague. I'll contact you
via email about it.
[...]
>
> There are tons of parts that need made and making some primitives for such
> parts would really help speed stuff up.
>
> Now, what are these blocks? See http://www.hirstarts.com. I have been in
> contact with Tim Courtney on this matter, and he has encouraged me to go forth
> with this effort, and to ask questions here, (BTW, I totally missed the
> l.c.d.parts.primitives group, or would have posted it there) on the newsserver,
> and to see if anyone here might be interested in helping with such a project.
You should definitely set this project up in a website - you never know
where help might come from.
> I would welcome your help, and would be more than willing to discuss this off
> list, if that would be better, but a little exposure for this project is partly
> the reason for my question.
As you know, I am intrigued by the possibilities of "parallel" libraries.
> Also, even tho most of the needed primitives are written, would not having docs
> on writing said primitves be a wise thing to have around anyway. Would not hurt
> to have them, for future generations, at least. Who knows what Lego will decide
> to put out for parts in 30 years. Then again, thats just my opinion. Your
> milage may vary.
You're struggling to bring your project together - same happens with
everyone else here ;-D
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dat.parts, Dwayne Miller writes:
> > > Looking for some form of Documenation, on MAKING not using Primitives.
> > > Prefer something that does not require a BS in math to understand.
> > So, I'm intrigued as to where you think the LDraw library could benefit from
> > more primitives.
>
> The LDraw Library for Lego Parts, nope, but as I am not making LDraw Parts for
> Legos, loads. Working with something similar to Legos (see my recent posts on
> l.d.c Question on the Future of LDraw family ) but not at all compatible. (IE
> they are not a lego clone or any such thing.)
>
> There are tons of parts that need made and making some primitives for such
> parts would really help speed stuff up.
>
> Now, what are these blocks? See http://www.hirstarts.com. I have been in
> contact with Tim Courtney on this matter, and he has encouraged me to go forth
> with this effort, and to ask questions here, (BTW, I totally missed the
> l.c.d.parts.primitives group, or would have posted it there) on the newsserver,
> and to see if anyone here might be interested in helping with such a project.
OK - now you've made it clear that this request is linked to the hirstarts
"project" I see the context of your question - which alters my response
somewhat.
You're free to develop non-Lego parts and primitives which can be rendered with
the LDraw tools, but if its outside of the LDraw library, then I think its up
to you to set your own standards and definitions. In basic terms, primitives
are nothing special - just a bunch of files in another directory in which the
LDraw tools are pre-configured to search.
Representing texture in LDraw .dat files is not easy, and whilst you won't need
a Maths qualification, it will help - if you want to go down that route.
You _may_ get some help here, but the focus of interest here is likely to be in
CAD for Lego parts, I'm afraid to say. Personally, whilst I admire the concept
of the self-moulded parts, I don't own any of these moulds, some am unlikely to
be able to make any meaningful contribution to interpreting them as .dat files.
One rule we do try to make is that part authors must have the physical part to
hand in order to accurately model it.
I suspect that most of the LDraw part authors have more than enough Lego parts
to keep them busy - I certainly do. Partly because we've done all the easy
parts - so what's left takes longer per part, partly because there's always new
parts appearing.
> > I'm happy for this discussion to happen here, or take off line with Steve
> > Bliss and myself at parts@ldraw.org. In any case, if you have ideas for new
> > _classes_ off primtives, we would want to be involved in the nomenclature.
>
> I would welcome your help, and would be more than willing to discuss this off
> list, if that would be better, but a little exposure for this project is partly
> the reason for my question.
Now I understand the context of your question I'd like to clarify this offer,
which was only made in the context of Lego LDraw primitives - of which there is
still some scope for development.
> Also, even tho most of the needed primitives are written, would not having docs
> on writing said primitves be a wise thing to have around anyway. Would not hurt
> to have them, for future generations, at least. Who knows what Lego will decide
> to put out for parts in 30 years. Then again, thats just my opinion. Your
> milage may vary.
Yes, documentation is always good, and is being improved all the time, but I
wouldn't place this very high on a priority list. We seem to be able to cope
pretty well in assessing new primitive development with the collective
experience of a few long-standing contributors.
>
> > Chris
>
> Thanks for your reply,
> Dwayne
> Barberton, Ohio USA
Sorry if this sounds downbeat. I do wish you luck with this project, and look
forward to seeing the first instructions generated with the LDraw tools, but I
don't have the time to assist with such a divergent project at this time.
Chris
| | | | | | |
