Subject:
|
Re: A comprehensive LDraw object model
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Sun, 10 Feb 2002 18:33:02 GMT
|
Viewed:
|
678 times
|
| |
|
|
In lugnet.cad.dev, Bernd Broich writes:
> Shall this lines be only container classes or shall they have the
> working code?
> If they have working code, they are heavily depending on the target
> system (renderer, filter, etc.), so I can't see the advantage of
> unifying them.
The way I designed my stuff is that the code in the linetype classes manage
the objects they contain -- mostly just allocation, serialization and
stringification of a matrix or a list of vectors. However, any rendering or
parsing behavior is outside the scope of these classes and is therefore up
to the renderer and parser, respectively.
> Else they are container classes, there have to be wrapper
> depending on the intention of the program. In this case we rebuild
> the dat-file structure.
That's exactly what I propose, is to rebuild the dat-file structure in an
object-oriented way.
> > class LDrawFile - a container for LineType objects, represents a single datfile
> > + class LDrawFileMulti - a container for LDrawFile objects, represents an
> > MPD file
> A LineType1 contains / is a LDrawFile, so you are splitting the line type 1 into
> two similar classes.
Actually, not quite. A line type 1 is merely a pointer to a container (i.e.
the part name points to the part's datfile). If a type 1 line actually
contained the subpart's component parts, you'd start filling up memory
pretty fast. Further, the container that a line type 1 points to is
specifically a datfile, not a multi-part datfile.
OTOH, the datfile format has been extended to simulate a single-depth
container of datfiles. Most LDraw tools correctly handle DATs and MPDs when
you use them as input. But with any of these tools, just try to put an MPD
partname in a line type 1 and things start to break.
This tells me that DATs and MPDs are different animals, and unrelated to
type 1 lines.
> > *** LDRAW DAT RENDERER CLASSES ***
> > abstract class LDrawRenderer - ancestor class for renderers
> > + class LDrawRendererOrthographic - renders LDraw.exe style
> This should not be declared because it prevents using different libraries
> (native code) on different systems. I think that this is highly differing
> from the programmer and it's tools.
How do you mean? If we were to implement an example renderer in 100% Java
(or Perl or Python, etc.), would that not be runnable on different systems
-- including systems where there's a Java (or Perl or Python, etc.) presense
but no native LDraw tools? The only libraries needed would be the JRE (or
Perl or Python, etc.) and this class library.
Please explain, as I'm not quite sold on this part of my class structure
anyway...
> > *** MATH CLASSES ***
> > abstract class MatrixNxN - ancestor class for transformation matrices
> > + class Matrix4x4 - a 4x4 transformation matrix
> > abstract class VectorN - ancestor class for vectors
> > + class Vector3 - a 3-element vector, useful for coordinates, euler angles,
> > RGB color values, etc.
> > + class Vector4 - a 4-element vector, useful for 4x4 Matrix math,
> > quaternions, etc.
> Hm, they should be only wrapper classes to underlying native code in the
> used language on the used system.
Show me a vector/matrix library that is (1) an accepted standard, (2) free
and readily available, (3) works on different systems, and (4) has hooks for
multiple languages such as Java and Perl. I desparately wanted one,
couldn't find one, so I implemented one. FWIW, it wasn't that big of a deal
to implement, just some review from my school math texts.
This argument has come up before, and I don't quite see the point. Based on
the premise that we shouldn't implement something because it's been done
before, we'd have only one LDraw renderer.
(insert patriotic music here)
We clearly have more than one LDraw renderer.
(patriotic music is slowly building volume)
But we *don't* have an easy way to write datfile filters, we *don't* have an
easy way to serve processed DAT content on the webserver end, we *don't*
have a cross-platform LDraw solution (1), and we *don't* have an easy way
for people to dabble in LDraw-related code.
This class library would address all of that.
(the now-heart-throbbing patriotic music reaches a crecendo)
And that's why I think it is a great idea.
(choir breaks into ahh's and the crowd goes wild ;-)
> The more you specify their working code
> the more you can't use local optimizations.
This raises an excellent point. The matrix library would be hammered the
most, so clearly a way to allow any kind of 3rd-party optimizations
(including linking in machine code) should be available. How about if we
make Vector* and Matrix* abstract base classes, and then provide a Java (or
Perl or Python, etc.) implementation as a baseline?
Cheers,
- jsproat
1. Okay, so we do have *some* cross-platform LDraw tools. Let's make some
more. Let's give the Mac crowd the same kind of CADding thrill we LDraw'ers
have.
|
|
Message has 2 Replies:
 | | Re: A comprehensive LDraw object model
|
| (...) Well, while I haven't tried it, I'm fairly sure that my implementation of MPD-handling in LDView would happily load an MPD file as a subfile of another MPD file or a dat file. :-) --Travis Cobbs (tcobbs@REMOVE.halibut.com) (23 years ago, 10-Feb-02, to lugnet.cad.dev)
| | | Re: A comprehensive LDraw object model
|
| "Sproaticus" <jsproat@io.com> schrieb im Newsbeitrag news:GrBy72.EJI@lugnet.com... (...) Conclusion: The LineType-classes are wrapper classes for the lines in the dat files. Simple in- and output methods are included, also simple transforming (...) (23 years ago, 11-Feb-02, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: A comprehensive LDraw object model
|
| "Sproaticus" <jsproat@io.com> schrieb im Newsbeitrag news:GrA7CA.24y@lugnet.com... (...) Shall this lines be only container classes or shall they have the working code? If they have working code, they are heavily depending on the target system (...) (23 years ago, 10-Feb-02, to lugnet.cad.dev)
|
30 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
