Subject:
|
Re: A comprehensive LDraw object model
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Sun, 10 Feb 2002 06:35:13 GMT
|
Viewed:
|
568 times
|
| |
|
|
In lugnet.cad.dev, Kyle McDonald writes:
> Sproaticus wrote:
> > abstract class LineType - ancestor class for all line-type objects
> > + class LineType0 - comment line-type
> > + class LineTypeCommand - command line-type
> Aren't all of these classes Abstract? I mean this is only a
> template for implementing a Class Library right? Are you planning
> on actually filling in the code also? or just defining the
> interfaces?
The base class is abstract, the ones not marked "abstract" aren't.
This class hierarchy is actually the class library I whipped up over the
past week. About 95% of what I posted here has working code, but I didn't
want to push any of that if there's no consensus on the higher-level design...
> > + abstract class PhysicalLineType - ancestor class for all physically
> > mutable line-types
> > + class LineType1 - subpart line-type
> > + abstract class PrimitiveLineType - ancestor class for all
> > line-segment-containing line-types
> So far you've got a few more levels in here than I used in my
> class hierarchy. Until more of the interface is laid out, though
> we won't really be able to tell if the extra layers provide value.
I think that these line type classes do provide value. For example, the
classes I derived from the PrimitiveLineType classes all basically contain a
list of Vector objects, and maintaining those lists is all done in the
PrimitiveLineType while the specifics are done in the child classes.
Similarly, the PhysicalLineType-derived classes have color atributes and
transformation details that are all handled in the PhysicalLineType class.
I guess I should've been clearer on this. :-,
> > + class LineTypeNull - blank line-type
> Well, do you need a Class for blank lines? Shouldn't the loader or
> parser just ignore them?
Sure, but I like the idea of using spaces in the output datfile to help keep
it at least semi-human-readable. At the moment, I'm also keeping track of
line indentation -- it's a minor cost during parsing and in storage, but
indented lines make an inlined datfile a bit easier to understand at a glance.
> > abstract class ModelLoader - ancestor class for all model loaders, model cache
> > + class DiskModelLoader - loads datfiles from local storage
> > + class HTTPModelLoader - loads datfiles from web repository
> There really shouldn't be much difference betweenn these should there?
> It seems to me if you had one routine that read from a Stream, then you
> could implement both of those as a wrapper easily enough.
Good point. You're absolutely correct. In the other three languages I'm
thinking of (C++, Python, and Perl) the sockets are abstracted into a stream
or stream-line interface, so there's really no reason to make separate loaders.
> > class ModelParser - parses a datfile into its component LineType objects
> This is an interesting idea. Maybe I'm not thinking about this right,
> but what would a separate parser do that the loader didn't already do?
> Or if you leave the work up to the Parser, what does the loader do?
> What does it read the data into?
Yah, it's still kinda vague, lemme see if I can lay out my ideas here.
The Loader works as a go-between for the Parser and the storage system
(disk, net, etc.). It also works as the model cache.
The Parser is invoked by the Loader to distill datfiles into objects.
I felt that these are different enough tasks to break them apart. For
example, keeping the parser apart would allow for future syntax or file
format changes, without requiring code changes to the loader.
> I'm not married to Java or Java3D, but it seems to me that
> most languages must have a good Matix/Vendor Math Library
> already, Do we need to redefine this? I would think this
> would be one of the thing Computer Science has already beat
> to death. No?
Okay, then. Show me one standard, currently-supported Matrix/Vector library
for C++. Python? Perl? There aren't any. There are many many
implementations out there, and they're all different. A lot of them come
with a price tag.
And until Java3D came out, there wasn't one for Java, and it seems you need
to install Java3D to access it. Do we want to require people to install a
5+Mb class library just to use the math parts? And even if it comes
standard in the JRE, I don't think we should tie this thing to just one
language.
Besides, it's not really that much to implement. My implementation of
Vector3, Vector4, and Matrix4x4 takes fewer than 600 lines of code; the
classfiles combined are about 15k. Next week I'll be implementing them in
Perl; I'm guessing that it'll be a cake walk.
> The big question that comes into my mind when thinking
> about things like this is: "How closely do we model this on
> LDraw?" What I mean, is that while the file format is useful
> and we need to handel it, I'm not sure that programs written
> in the future will want to be locked into using the same data
> structures internally as the are used in the file.
That's a very good point, and one that's been bothering me. What I came up
with was this: if we don't model the class library towards the LDraw file
format, what do we model it towards, then?
I don't have a whole lot of experience with 3d programming, though. There
could be some fantastically wonderful standard model out there, and I'd
never know. :-,
I *kinda* like how POVRay handles 3d objects, where everything is either a
canned geometrical shape or is derived from combinations thereof. But I
understand that CSG math can get pretty hairy...
Ultimately, though, my goal for developing a class library for LDraw is so
that there's a class library for LDraw. It needs to be applicable to what's
out there now; and people with programming skills and who are familar with
LDraw syntax should be able to use it.
> (actually I wonder if defining a
> renderer is worth it at all if we're not going to fill it
> with real code.)
Oh yeah, any reference implementation would have to have real code.
> Programs need to be able to tweak, massage,
> and do whatever they want with the primitives inorder to
> optimize the capabilites of their program.
I see this not as an opportunity to develop a highly-optimized program, but
to provide a framework within which others can develop, period. There are
already high-performance renderers available if you're looking for
performance. But is there a decent command-line model inliner? Or a bezier
hose generator that isn't tied to a text editor or a spreadsheet? Or any
appreciable set of LDraw tools that run on a Macintosh? Let's get those out
first, then worry about optimizations. This class library would perhaps be
best-suited to developing specialized tools, though there's really no reason
it couldn't be used for a datfile editing suite.
Also, the source code for this class library would be available, and if
anyone wants to take it, optimize it, and use it in their own applications,
I don't see anything wrong with that.
> I would think
> Authors this will lead Authors to want to do things in the
> renders that might be limited by any render interface we
> might come up with.
Dunno. It's not all about rendering (though that is arguably the final
destination for any datfile). I absolutely love the idea of LDraw file
filters. I have one filter that inlines a datfile, another that takes
transformation commands from comment lines and applies them to blocks of
type-1 lines. Michael Horvath has just recently indicated his desire for a
filter that removes hidden lines and surfaces. Requests for various filters
have come up in the past, with no one writing them.
A side note: I'm starting to warm up to the idea of using a scripting
language -- Python or Perl (probably Jython for now, until someone ports
Perl to Java :-) -- as part of the user interface in an LEdit-like app. The
closest thing I can think of is user macros in a spreadsheet or text editor.
The fact is, that there's so much flexibility that such a framework could
provide, that the limitations might not be so much of an issue.
> What do you think?
I think that traffic in Salt Lake City is pretty much congested for the next
two or three weeks. Everything else is pure conjecture. ;-)
Cheers,
- jsproat
|
|
Message has 2 Replies:
 | | Re: A comprehensive LDraw object model
|
| (...) Ok. Up until now I've been under the impression we were trying to come up with a pure interface definition, independent of any particular language, platform, or implementation. When I asked if they weren't all abstract, I was envisioning (...) (22 years ago, 10-Feb-02, to lugnet.cad.dev)
| | | Re: A comprehensive LDraw object model
|
| (...) OK. This is sounding very yummy. When can we start using the frameworks. (...) Nonsense. I got to work and home just fine today, and I even found parking right across from where they had the opening ceremonies. :-) James (22 years ago, 12-Feb-02, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: A comprehensive LDraw object model
|
| (...) Aren't all of these classes Abstract? I mean this is only a template for implementing a Class Library right? Are you planning on actually filling in the code also? or just defining the interfaces? (...) So far you've got a few more levels in (...) (22 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
|
|
|
|
