Subject:
|
Re: A comprehensive LDraw object model
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Sun, 10 Feb 2002 22:52:56 GMT
|
Viewed:
|
816 times
|
| |
|
|
Sproaticus wrote:
>
> 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...
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 something
that each developer builds off of:
abstract class LineType - ancestor class for all line-type objects
+ abstract class LineType0 - comment line-type
+ class JSproatLineType0
+ class KJMLineType0
+ abstract class LineTypeCommand - command line-type
+ class JSproatLineTypeCommand
+ class KJMLineTypeCommand
etc.
>
> > 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. :-,
OK. If you could find things they shared, then the extra levels
are useful. I'm usually one who trys to add in these levels just
for completeness sake, I'll have to go over my code and see if
I missed something ;) I'll agree though any interface spec should
be complete and offer as many jumping off points for developers as
possible.
>
> > > + 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.
Ahh. I see.
Yes I suppose, for both reading and writing (it was the writing I'd
forgotten about) DAT files it might be best to at least preserve the
whitespace. I can even see use for programs that 'reformat' DAT files
just like we have some that do the same for C and Java.
>
> 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.
How is this different from Java? You can get a Stream from a URL in
Java too right? I haven't done anything with URL's in Java so far, but
I think it's pretty much the same.
>
> 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.
Hmmm. I can see that I think. I think we really need to start defining
Methods and Dataflow to really be able to see all this. What data
structures are used to pass the file contents from the loader to
the parser?
There are some free UML tools. Maybe we ought to move this into
one of those so we all can get a bette ridea of what we're talking
about?
>
> 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.
I don't know those languages that well. I have to think C++ has some
library somewhere already. Doesn't PovRay need/have one? As for them
all being different, you're going to have to rewrite this in each
language anyway... Why do they need to work the same way?
You're not going to be able to have one implementation of this interface
in all the languages anyway, letting each implementation select it's
own matrix library doesn't seem that bad.
The important thing to me is the DAT specific stuff. How a specific
implementation ends up getting it's matrix math done, to me is an
implementation detail we shouldn't need to worry about. You use the
one you wrote, I'll use the one in J3D, someone in C++ might use the
one from POVray (I'm guessing they have one in there some where?)
Someone else might write one from scratch also. All I'm saying is,
maybe we should leave this open to who ever ends up implementing it
later.
>
> 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.
I understand that. I'd also like to not tie people into using something
when the language/platform they've chosen has a better alternative.
And I agree DL'ing J3D just for a VecMath library is asking too much,
though It really wouldn't surprise me if it does endup in 'standard'
Java someday soon. I'd just think it'd be better for any standard to
leave implementer the choice of taking advantage of whatever is
available.
>
> 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.
You're right it's not that big a deal to write, but what if someone
wants to take advantage of library that is writen to use matrix/vector
HW on the platform they use. That's just an example. People are
going to write their own implementations of this interface.
>
> > 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've been thinking that this really depends on how much of this
you want to standardize.
Definately, coming up with an API to read and write DAT files
is a good idea, and it really should be organized around how
DAT files are laid out.
It's after that that my questions, and (I think Larry's also)
come up. Do we model more than that? If we do, Do we objectify
the current LDraw organization? or do we design something new,
and make the DAT IO library interface well to it?
>
> 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. :-,
Well in general, The idea of a Scenegraph ( tree of transforms
and geometry) is a very good fit to the DAT organization.
Scengraphs aren't all that new I don't think, but they have been
getting more attention lately. Though I'll admit I'm no 3D expert
either.
> 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.
>
> Oh yeah, any reference implementation would have to have real code.
I think first you need to decide what the interface you're
going to implement is going to look like. I'm sure there
are others around here who are more OOD experts than me
(Larry, is this one of the things you do for a living?,)
but in my experience it helps to back of from the language,
platform, previous code, etc. and focus on the problem
when trying to design the interfaces.
>
> > 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.
I'm not saying we need to optimize this now. Just that we need
to keep it in mind when designing an interface that people
won't want/need to go around later when they do want to add that
stuff.
> 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.
Will they need to change the interface when they make the
Optimizations though?
One of my favorite things about Java is that an application
can actually switch implementations of an interface at
run time, without restarting let alone recompiling. I see
what you've proposed as a great way to use that feature in
LDRraw apps, but that only works if the interface on the
different implementations are 100% the same, and that means
designing an interface that everyone can work inside of early
on. If we decide on a Java LDraw renderer interface say, I'd
like to be able to load different ones into my app, kinda
like plugin's to make use of the advantages they offer.
WIthout a solid interface standard, I don't see this happening.
Actually going back to the idea of starting with an
interface to load and write DAT files, and building from
that. I'd like to seriously consider using the Java3D
loader interface on the java platform for just the reason
I've mentioned above. This interface that Java3D has
defined, allows people to write what are basically
'plugins' that read and write different file formats.
Having a DAT file plugin that conformed to this
interface would make it loadable in all sorts of Java
Apps. And I don't think that would make things depend
on J3D either. The classes should be useable standalone
I would think. However if an Application actually used
the the classes through the interface, it would open
itself up to many many other 3D file format libraries
that already exist out there... VRML, 3DS, LWO, LWS, etc...
Now should the other languages/platforms use the same
interface? I don't know. But I also don't think keeping
the interface identical between languages is a requirement
either - especially if it precludes us from making use
of features that platform has.
>
> 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.
Hmmm. Inlining Sub-models I can understand. I think I read
Micheal's post differently from you though. The way you put it,
it seems you'd need to inline the model all the way down, even
through to the primitives, and then compute and gut the model
of all the surfaces and lines that were hidden in the current
view.
I'm not sure what advantage this has. For one, the Model isn't
really an LDraw model anymore, it wouldn't refer to any of the
parts in the library anymore. It might as well be a pure 3D
geometric model. Second, depending on how far you took the hidden
surface removal, the model may only be useful from the one viewpoint
after that. You sure couldn't load it into a LDraw tool to continue
to work on it (unless you like working at the triangle and quad
level :) ). The model files are also likely to grow significantly
this way also if they end up with all the tris and quads repeated
over and over in them.
The way I interpreted his email, was more to code the info on
the 'internal' geometry into the part files themselves so that
an application could switch them on and off at runtime to improve
performance, without actually changing the DAT model at all.
> 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
> would provide, that the limitations might not be so much of an issue.
>
This is interesting, but I'm not sure what effect it has on
what we're discussing. Not that it doesn't - just that I haven't
thought it all out yet.
> > 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. ;-)
I can imagine. Have you gone to any events yet?
-Kyle
|
|
Message has 1 Reply:
 | | Re: A comprehensive LDraw object model
|
| "Kyle McDonald" <kmcdonald@bigfoot.com> schrieb im Newsbeitrag news:3C66F9C8.207030...oot.com... (...) I have made two charts, one for file loading and one for file structure (URL) this location I can place futhermore our conclusions, when we get (...) (22 years ago, 12-Feb-02, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: A comprehensive LDraw object model
|
| (...) 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 (...) (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
|
|
|
|
