> -----Original Message-----
> From: L3DT_users_group@yahoogroups.com
> [mailto:L3DT_users_group@yahoogroups.com] On Behalf Of Aaron Torpy
> Sent: Tuesday, November 15, 2005 11:03 PM
> To: L3DT_users_group@yahoogroups.com
> Subject: RE: [L3DT users' group] SDK progress report
>
  > Sounds like the network stuff might be very handy
> > for the Middle Earth DEM Project.
>
> I hope so...ME-DEM was one of the projects I had in
> mind when I proposed the network stuff

Yay! <G>

> (the other main
> one being Beowulf clustering of map calculations, for
> huge maps in a hurry, and for the 'cool' factor).

Yeah, that would be pretty cool. Then all you need is a program that can
load those monster data sets. ;)

> For the benefit of the group-members not familiar with
> ME-DEM (http://me-dem.ashundar.com), it is an
> ambitious project to create a digital elevation map of
> 'Middle Earth', from J.R.R. Tolkien's Lord of The
> Rings, et. al. At my last reading, the goal is to make
> a 20k x 20k pixel final heightmap.

Unfortunately for us that's just the very first stage. That's our starting
point. It just gets worse from there, hehe. The 20k map is I believe 200
meters per pixel. We want to cut that down to about 10 eventually. So once
we have the 20k map, derived from hand-drawn maps of various sources (and
covering only a portion of Middle Earth mind you - about 1/4 I think), we
divide up into 100x100 tiles (I think - or maybe 200x200) and scale by 10
times to get 1000x1000 pixel terrains. Those terrains are then refined by
hand to get more realistic detail at 20m/pixel. Then we divide again to get
the 10m (or better) data and refine again by hand. I forget the actual
numbers but we'll actually end up with literally 10's of thousands of
terrain tiles of 1000x1000 or something. It's pretty scary. And that's just
for 1/4 (or less) of the whole world. :p

> Since the
> terrain-shaping has to be (at-least partially) manual
> to get the right result, the project will require an
> awful-lot of person-hours to build a map that large.

Yeah, multiply "awful-lot" by 1000 given the above. <G>

> One of the ideas that's been proposed to help-out is
> the creation of a distributed server/client system so
> that individual contributors can chip away at small
> areas and send back the results without causing nasty
> duplication or edge mismatch problems.

Indeed. Another thing that would help is if we could load up our base maps
in L3DT and use an extension of the current terrain definition system to add
semi-directed procedural detail to our base terrains. We're getting closer
to that now as L3DT gains capability.

> > If we could utilize this to setup a master file list
> on a
> > server and have a check-in/check-out system, simple
> map-based
> > GUI tile selection with automated tile positioning
> after edit
> > and upon export, and perhaps even some way to match
> up
> > tile edges... well, it'd help us out a helluvalot.
>
> Hmm...I think I can see how all that would work. The
> tile-edge matching could be tricky, but I guess we
> could always forbid the editing of a 1px-thick border
> of the downloaded area (if you want to edit those
> bits, download the surrounding tiles too).

That's kind of a non-ideal solution. It would probably result in pretty
harsh lines if a larger area was not edited. And ultimately there will
always be tile edges, whether you're working with 4 1000 pixel tiles (so the
4 interior seams are covered, but there are still 4 edge seams), or a single
1000 pixel tile. A better solution is needed I think.

> Then-again,
> there's always the option of linear (or non-linear)
> blending of overlapping tile edges. I'd rather avoid
> this 2nd option, though, since it would add
> complications to the server.

It may be necessary given the above. Or some sort of overlap system perhaps?
Ultimately we want to have a bunch of equal tiles that can be downloaded and
glued together to form one contiguous terrain covering any area you want,
without seams. So the seam issue is critical.

> As for the other stuff, it's conceptually pretty neat
> 'n' tidy. All the network socket code would go into a
> common plugin. The map server could be a stand-alone
> program independent of L3DT, but using the SDK and
> relevant plugins. The client-side would preferably be
> a plugin for L3DT, but could initially be a
> stand-alone job too (just to keep it simple).
> Firewalls/NATs/etc can be worried about later.

Good, good...

> Anyhow, it's a good think that ME-DEM is a long-term
> project, because there's an awful lot of coding to
> make that stuff work.

Yeah, loooong term. We're definitely on the long track. <G>

> I'll start playing around with
> it early/mid next year, hopefully once I've got a nice
> beta-release of the SDK going.

Sounds great to me! I'm looking forward to it. :)

I'll tell you right here ideally we'd like to get several developers
involved, brainstorming on how to address these problems. We figure if the
software can be made free or open source or something, it'll probably be
applicable to other people's projects too. Maybe even commercial endeavors.
Or it can at least be made general enough that that would be the case. So
eventually it'd be great if you and Ray of Leveller and Stephen of World
Machine and the Wilbur guy (forgetting his name right now) all got together
and made us a kick ass app/system/framework/dingly. And then I woke up from
my beautiful dream. ;)

- Oshyan

Hi Oshyan,

> Sounds like the network stuff might be very handy
> for the Middle Earth DEM Project.

I hope so...ME-DEM was one of the projects I had in
mind when I proposed the network stuff (the other main
one being Beowulf clustering of map calculations, for
huge maps in a hurry, and for the 'cool' factor).

For the benefit of the group-members not familiar with
ME-DEM (http://me-dem.ashundar.com), it is an
ambitious project to create a digital elevation map of
'Middle Earth', from J.R.R. Tolkien's Lord of The
Rings, et. al. At my last reading, the goal is to make
a 20k x 20k pixel final heightmap. Since the
terrain-shaping has to be (at-least partially) manual
to get the right result, the project will require an
awful-lot of person-hours to build a map that large.
One of the ideas that's been proposed to help-out is
the creation of a distributed server/client system so
that individual contributors can chip away at small
areas and send back the results without causing nasty
duplication or edge mismatch problems.

> If we could utilize this to setup a master file list
on a
> server and have a check-in/check-out system, simple
map-based
> GUI tile selection with automated tile positioning
after edit
> and upon export, and perhaps even some way to match
up
> tile edges... well, it'd help us out a helluvalot.

Hmm...I think I can see how all that would work. The
tile-edge matching could be tricky, but I guess we
could always forbid the editing of a 1px-thick border
of the downloaded area (if you want to edit those
bits, download the surrounding tiles too). Then-again,
there's always the option of linear (or non-linear)
blending of overlapping tile edges. I'd rather avoid
this 2nd option, though, since it would add
complications to the server.

As for the other stuff, it's conceptually pretty neat
'n' tidy. All the network socket code would go into a
common plugin. The map server could be a stand-alone
program independent of L3DT, but using the SDK and
relevant plugins. The client-side would preferably be
a plugin for L3DT, but could initially be a
stand-alone job too (just to keep it simple).
Firewalls/NATs/etc can be worried about later.

Anyhow, it's a good think that ME-DEM is a long-term
project, because there's an awful lot of coding to
make that stuff work. I'll start playing around with
it early/mid next year, hopefully once I've got a nice
beta-release of the SDK going.

Cheers,
Aaron.


--- Oshyan Greene <oshyan@...> wrote:

> > -----Original Message-----
> > From: L3DT_users_group@yahoogroups.com
> > [mailto:L3DT_users_group@yahoogroups.com] On
> Behalf Of Aaron Torpy
> > Sent: Monday, November 07, 2005 6:38 AM
> > To: L3DT_users_group@yahoogroups.com
> > Subject: Re: [L3DT users' group] SDK progress
> report
> >
> <snip>
> > Oh yes, I forgot to mention in the previous mail
> that
> > other planned plugins include:
> > * Standard dialogs and controls (in dev.)
> > * Some sort of 3D terrain renderer.
> > * Client/server socket communication (TCP, UDP).
> > * Encryption/hashing (AES and SHA-256)
> >
> > Not all of these will make it into the first
> > beta-release (probably only crypto and dialogs),
> but
> > these will be nice little side-projects for me to
> toy
> > with. I've written (and re-written, a zillion
> times)
> > the asynchronous encrypted network socket stuff
> for
> > work, so I think it would be nice to apply that
> > knowledge to L3DT. Perhaps a network-distributed
> > calculation manager (L3DT@home, anyone?). <snip>
>
> Sounds like the network stuff might be very handy
> for the Middle Earth DEM
> Project. We were talking at one point about how to
> synchronize as much work
> as possible, including keeping tiles
> "georeferenced", matching tile edges,
> making sure no work is duplicated, etc. If we could
> utilize this to setup a
> master file list on a server and have a
> check-in/check-out system, simple
> map-based GUI tile selection with automated tile
> positioning after edit and
> upon export, and perhaps even some way to match up
> tile edges... well, it'd
> help us out a helluvalot. <G> We desperately need
> tools to speed up our
> workflow. Unfortunately none of us are really
> programmers, as far as I know,
> but this will at least be one step closer. Sounds
> like it'll be a great
> addition to the L3DT system. :)
>
> - Oshyan
>
>

Hi Oshyan,

Ah, I should have read the fine-print. 400x300 is
pretty crappy, so I think we can scratch that idea. As
you are indeed the guru in such things, I'll send you
an e-mail privately to discuss setting up a proper
CMS.

Cheers,
Aaron.

--- Oshyan Greene <oshyan@...> wrote:

> Unfortunately, to the best of my knowledge, the
> Yahoo "galleries" such as
> they are only allow a max *displayed* image size of
> 400x300. You can upload
> larger images, but they'll only display to the
> uploader at that size - other
> viewers will only see the small size. One more
> reason why we ought to
> migrate away from here ASAP IMO. You could put up a
> Coppermine or Gallery 2
> install in no time and we'd have a great gallery
> system that would allow any
> size of image. A decent CMS would also allow links,
> etc. just like here.
>
> - Oshyan
>
> > -----Original Message-----
> > From: L3DT_users_group@yahoogroups.com
> > [mailto:L3DT_users_group@yahoogroups.com] On
> Behalf Of Aaron Torpy
> > Sent: Monday, November 14, 2005 9:42 PM
> > To: L3DT_users_group@yahoogroups.com
> > Subject: [L3DT users' group] Images and links
> >
> > Hi All,
> >
> > It just caught my attention that Yahoo Groups has
> allocated 30Mb for
> > the photo gallery. It's not much, but we may as
> well use it. If you
> > want to show-off any lovely screenies of your
> projects, please feel
> > free to upload them to the 'photos' section. I've
> created 'best
> > images' gallery for works of which you are
> particularly proud. If you
> > want to post a set of images, please create your
> own sub-gallery off
> > the 'Users' galleries' folder and upload to there.
> Since we haven't
> > got all that much space, I'd prefer it if you keep
> the image size to
> > 1024x768 or smaller, and use JPEG compression
> whenever possible.
> >
> > Also, if you want to add links to anything, the
> 'links' page is the
> > place to do it. I've created folders for 'users'
> projects' and
> > 'tutorials'. If you can think of other useful
> categories, please add
> > them.
> >
> > I'll be laissez-faire with the moderation of
> content, but I would
> > prefer it if links/photos are vaguely on-topic and
> mostly inoffensive.
> >
> > Cheers,
> > Aaron.
>
>

Unfortunately, to the best of my knowledge, the Yahoo "galleries" such as
they are only allow a max *displayed* image size of 400x300. You can upload
larger images, but they'll only display to the uploader at that size - other
viewers will only see the small size. One more reason why we ought to
migrate away from here ASAP IMO. You could put up a Coppermine or Gallery 2
install in no time and we'd have a great gallery system that would allow any
size of image. A decent CMS would also allow links, etc. just like here.

- Oshyan

> -----Original Message-----
> From: L3DT_users_group@yahoogroups.com
> [mailto:L3DT_users_group@yahoogroups.com] On Behalf Of Aaron Torpy
> Sent: Monday, November 14, 2005 9:42 PM
> To: L3DT_users_group@yahoogroups.com
> Subject: [L3DT users' group] Images and links
>
> Hi All,
>
> It just caught my attention that Yahoo Groups has allocated 30Mb for
> the photo gallery. It's not much, but we may as well use it. If you
> want to show-off any lovely screenies of your projects, please feel
> free to upload them to the 'photos' section. I've created 'best
> images' gallery for works of which you are particularly proud. If you
> want to post a set of images, please create your own sub-gallery off
> the 'Users' galleries' folder and upload to there. Since we haven't
> got all that much space, I'd prefer it if you keep the image size to
> 1024x768 or smaller, and use JPEG compression whenever possible.
>
> Also, if you want to add links to anything, the 'links' page is the
> place to do it. I've created folders for 'users' projects' and
> 'tutorials'. If you can think of other useful categories, please add
> them.
>
> I'll be laissez-faire with the moderation of content, but I would
> prefer it if links/photos are vaguely on-topic and mostly inoffensive.
>
> Cheers,
> Aaron.

Hi All,

It just caught my attention that Yahoo Groups has allocated 30Mb for
the photo gallery. It's not much, but we may as well use it. If you
want to show-off any lovely screenies of your projects, please feel
free to upload them to the 'photos' section. I've created 'best
images' gallery for works of which you are particularly proud. If you
want to post a set of images, please create your own sub-gallery off
the 'Users' galleries' folder and upload to there. Since we haven't
got all that much space, I'd prefer it if you keep the image size to
1024x768 or smaller, and use JPEG compression whenever possible.

Also, if you want to add links to anything, the 'links' page is the
place to do it. I've created folders for 'users' projects' and
'tutorials'. If you can think of other useful categories, please add
them.

I'll be laissez-faire with the moderation of content, but I would
prefer it if links/photos are vaguely on-topic and mostly inoffensive.

Cheers,
Aaron.

> -----Original Message-----
> From: L3DT_users_group@yahoogroups.com
> [mailto:L3DT_users_group@yahoogroups.com] On Behalf Of Aaron Torpy
> Sent: Monday, November 07, 2005 6:38 AM
> To: L3DT_users_group@yahoogroups.com
> Subject: Re: [L3DT users' group] SDK progress report
>
<snip>
> Oh yes, I forgot to mention in the previous mail that
> other planned plugins include:
> * Standard dialogs and controls (in dev.)
> * Some sort of 3D terrain renderer.
> * Client/server socket communication (TCP, UDP).
> * Encryption/hashing (AES and SHA-256)
>
> Not all of these will make it into the first
> beta-release (probably only crypto and dialogs), but
> these will be nice little side-projects for me to toy
> with. I've written (and re-written, a zillion times)
> the asynchronous encrypted network socket stuff for
> work, so I think it would be nice to apply that
> knowledge to L3DT. Perhaps a network-distributed
> calculation manager (L3DT@home, anyone?). <snip>

Sounds like the network stuff might be very handy for the Middle Earth DEM
Project. We were talking at one point about how to synchronize as much work
as possible, including keeping tiles "georeferenced", matching tile edges,
making sure no work is duplicated, etc. If we could utilize this to setup a
master file list on a server and have a check-in/check-out system, simple
map-based GUI tile selection with automated tile positioning after edit and
upon export, and perhaps even some way to match up tile edges... well, it'd
help us out a helluvalot. <G> We desperately need tools to speed up our
workflow. Unfortunately none of us are really programmers, as far as I know,
but this will at least be one step closer. Sounds like it'll be a great
addition to the L3DT system. :)

- Oshyan

Nice, but maybe update the news section at the old web site with this
information, since right now the last news message there is still from
  September 6...

--- In L3DT_users_group@yahoogroups.com, "Aaron Torpy"
<aaron_torpy@y...> wrote:
>
> Hi Everyone,
>
> I'm very sorry that I've been so quiet of late. If I haven't replied
> to your emails yet, I will try to do so in the next few hours.
>
> The big news is that L3DT has finally moved to a new web-host:
> http://www.bundysoft.com/L3DT/
>
> If you've had trouble downloading the beta installer from Yahoo,
> please try the following options:
>
> For a fresh install of L3DT 2.3b Professional:
> <http://www.bundysoft.com/L3DT/downloads/professional/L3DT Pro
Setup.exe>
>
> To update an existing installation to L3DT 2.3b Professional:
> <http://www.bundysoft.com/L3DT/downloads/professional/L3DT Pro
Update.exe>
>
> The `standard edition' of L3DT 2.3b has been released for public use,
> but the `professional edition' is still in the beta-stage because
> bug-reports are still trickling in.
>
> In other news, there has been quite a bit of progress made on the SDK.
> I'll post another message shortly to explain what's happening and
> what's planned.
>
> Cheers,
> Aaron.
>

Hi Michael,

If I've answered this already, please ignore. I'm
starting to loose track on this thread.

I know absolutely nothing about programming in C#,
other than it's a little bit Java, which I also know
nothing about. Now, as for VB, I don't know anything
there either. This is a bit sad really. I might go out
and get a couple of programming books.

Anyhoo, as I may have said earlier on this thread
(somewhere), I'll release the C/C++ wrapping code
first, and then look at other languages once we've all
decided what needs to be changed.

Cheers,
Aaron.


--- Michael & Kristina Horton <mkhorton@...>
wrote:

> I'm learning both C++ and C#, primarily C# at the
> moment. But if it would be
> too difficult to make the C# one, I wouldn't mind if
> you didn't pursue it.
> Your time is probably better spent elsewhere.
>
> One thing though, it seems the large percent of the
> guys at TV3D (where I
> first heard about L3DT) use VB6 and VB.net.
>
>
>
> 3) What programming language(s) do you use? (I've
> written nice
> wrappers for C/C++, but that's it so far).
>
>
>
>
>
>
>
> [Non-text portions of this message have been
> removed]
>
>

Hello,

I agree with the C++ is faster than Java bit, but if the Java zealots
are to be believed the difference isn't that great these days. It
probably depends on what you're doing, of course.

As far as portability goes, Java is great. However, since the core
DLLs in the SDK will be windows binaries, portability is a bit of a
moot point here. It will only work on Windows, for the foreseeable
future, at least.

Is Java really clearer and easier? I know this is a preference thing,
and I am *clearly* biased towards C++, but I can distinctly recall a
colleague of mine was cursing SUN like a sailor when he had to program
in Java (a VC++ boy, normally). That's not to say I don't curse
Microsoft either, but it's usually to do with the IDE or linker,
rather than the language or compiler. Anyway, he was ranting something
about not being able to copy integers and floats into a binary
byte-buffer for network transmission, so he had to lash-up some ugly
code to send them as formatted strings. But that was a couple of years
ago, so maybe things have changed.

Maybe he didn't know what he was doing.

Maybe my memory is shoddy.

Yeah, probably the latter.

Anyhoo, I agree that the virtual machine is pretty a neato idea, so
long as you can still do everything that you want to do.

So there's my two cents on a subject I know little about.

Cheers,
Aaron.

PS: Java zeolots, please flame away!


--- In L3DT_users_group@yahoogroups.com, "Admin Kiraya" <kiraya@h...>
wrote:
>
> sorry but java is not faster than c++.
> it's only clearer,easiest and portable (because have virtual machine).
>
>   ----- Original Message -----
>   From: mark troutt
>   To: L3DT_users_group@yahoogroups.com
>   Sent: Tuesday, November 08, 2005 1:37 PM
>   Subject: Re: [L3DT users' group] Re: SDK progress report
>
>
>   Well, when I say "besides maybe java" I don't mean to imply that
I've ever
>   used it. All I know is that it can be more portable to other operating
>   systems and that it's supposed to be faster. I've never looked
into actually
>   coding in it :) . Sorry for the confusion. I was just saying that
I wouldn't
>   ever consider vb or vb.net <http://vb.net> for my games but I use
c++ and
>   would consider java, maybe.
>   -Mark
>
>   On 11/7/05, Aaron Torpy <aaron_torpy@y...> wrote:
>   >
>   > Hi Mark,
>   >
>   > > (besides maybe java...)
>   >
>   > I'm terribly ignorant of Java, but from what little I
>   > have read, it seems that it can be a bit of a pain in
>   > importing 'non-managed' functions from DLL. Can you
>   > shed any light on this unsupported assertion?
>   >
>   > > now you have votes of 5 out of 5 for most things :)
>   >
>   > Great! I love it when decisions are unanimous.
>   >
>   > Cheers,
>   > Aaron.
>   >
>   > --- mark troutt <marktroutt@g...> wrote:
>   >
>   > > Wow, I missed so much stuff in one day. Well Aaron
>   > > for your answers:
>   > > 1. I think everything I want/need has already been
>   > > included or mentioned.
>   > > 2. For standard I think that I'm all set. All I
>   > > really need is the
>   > > ability to import it directly into my format.
>   > > Currently I've been
>   > > having to use a script I made for 3ds max to turn
>   > > heightmaps into
>   > > terrain so I can export it from there.
>   > > 3. C++ all the way. VB is too slow for me and I
>   > > have gotten too
>   > > situated with C++ to use anything else (besides
>   > > maybe java...).
>   > > 4. I'd rather use a dll. Makes it easier on me.
>   > > 5. No unicode. I don't use it and I'm not planning
>   > > to anytime soon
>   > > (not within the next 40 years) so it isn't
>   > > neccesary.
>   > >
>   > > So that is my two cents and now you have votes of 5
>   > > out of 5 for most
>   > > things :) .
>   > >
>   > > -Mark
>   > >
>   > > On 11/7/05, Noisecrime_PIPEX <atic73@d...>
>   > > wrote:
>   > > >
>   > > >
>   > > > ----- Original Message -----
>   > > > From: "Aaron Torpy" <aaron_torpy@y...>
>   > > >
>   > > >
>   > > > > Hmmm....I'm not sure I'll be putting
>   > > *everything* into
>   > > > > the SDK. I really envisioned the SDK to be an
>   > > easy
>   > > > > tool with which other people can write file
>   > > > > converters, and build their own map-handling
>   > > > > applications.
>   > > >
>   > > > I think i misunderstood what you meant, I
>   > > thought you meant including
>   > > > plugins in general, not plugin access or code
>   > > into the sdk.
>   > > >
>   > > >
>   > > > > As for the
>   > > > > terrain renderer plugin, I've been wanting to
>   > > try my
>   > > > > hand at this for a number of years now.
>   > > >
>   > > > Well see you in another few years then ;)
>   > > >
>   > > >
>   > > > > So long as you're using C++, there is hardly
>   > > any
>   > > > > setup. You only need to include 'zeolite.lib'
>   > > in your
>   > > > > linking list, add a few .cpp and .h files to
>   > > your
>   > > > > workspace, and then throw-in a couple of
>   > > '#includes'
>   > > > > and one 'extern' statement at the top any cpp
>   > > files
>   > > > > that use the SDK.
>   > > >
>   > > > Sounds good, I've done a few dll plugins (heck
>   > > Director is built around
>   > > > them, but they are called xtras). I did start to
>   > > work on one for Gile[s],
>   > > > but as ever real-life got in the way. So
>   > > hopefully i'm up to speed enough
>   > > > to
>   > > > get it working.
>   > > >
>   > > >
>   > > > > I wish you the best of luck, and
>   > > congratulations on
>   > > > > your excellent SW3D demos (I was just browsing
>   > > your
>   > > > > website). I was rather blown away by the
>   > > > > shadow-mapping, water-reflection and
>   > > texture-splatting
>   > > > > demos. Really outstanding!
>   > > >
>   > > > Thanks, those are getting pretty old now, in
>   > > fact much of my more recent
>   > > > work isn't even online.
>   > > >
>   > > > One really nice project I did, that the L3DT sdk
>   > > would have been really
>   > > > nice
>   > > > for was Scalextric and their new Sportworld
>   > > product. I wrote the complete
>   > > > 3d
>   > > > editor, which they liked so much they've
>   > > released it as a standalone
>   > > > product. (
>   > > >
>   > >
>   >
>   >
http://www.slotforum.com/forums/index.php?s=7e5384810bf0d8f2115151d974c7fb8b&sho\
wtopic=10876
>   > > > )
>   > > >
>   > > > I'm currently working on a train simulator,
>   > > which i'd love to use L3DT to
>   > > > produce the terrain environment, but with a
>   > > duration of less than 3 weeks,
>   > > > i
>   > > > have no time to pursue it. Maybe in a version 2.
>   > > >
>   > > > I've also had some success using L3DT output
>   > > with Director, basic stuff at
>   > > > first like loading the hieghtmap data. But more
>   > > recently using Glex, an
>   > > > xtra
>   > > > i've written with a collegue that intercepts the
>   > > opengl code path of sw3d
>   > > > allowing us to add new abilities, such as
>   > > shaders, which I used with the
>   > > > alpha maps for terrain splatting.
>   > > >
>   > > > Sadly I ran out time to get it working at any
>   > > level to show, but its still
>   > > > on the backburner.
>   > > >
>   > > >
>   > > > Noisecrime 2005
>   > > > http://www.noisecrime.com
>   > > >
>   > > >
>   > > >
>   > > > ________________________________
>   > > > YAHOO! GROUPS LINKS
>   > > >
>   > > >
>   > > > Visit your group "L3DT_users_group" on the web.
>   > > >
>   > > > To unsubscribe from this group, send an email
>   > > to:
>   > > > L3DT_users_group-unsubscribe@yahoogroups.com
>   > > >
>   > > > Your use of Yahoo! Groups is subject to the
>   > > Yahoo! Terms of Service.
>   > > >
>   > > > ________________________________
>   > > >
>   > > >
>   > >
>   > >
>   > > --
>   > > Gravity. It's not just a good idea, it's the law.
>   > >
>   >
>   >
>   >
>   > SPONSORED LINKS
>   >   Medical software
program<http://groups.yahoo.com/gads?t=ms&k=Medical+software+program&w1=Medical+\
software+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backup\
+software+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=\
177&.sig=H4YaistW4xiEohGSob9qig>
Email
>   > software
program<http://groups.yahoo.com/gads?t=ms&k=Email+software+program&w1=Medical+so\
ftware+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backup+s\
oftware+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=17\
7&.sig=PdYAtHlttFUdWUXdTCGCIg>
Wedding
>   > program
software<http://groups.yahoo.com/gads?t=ms&k=Wedding+program+software&w1=Medical\
+software+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backu\
p+software+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s\
=177&.sig=ozUUVqwSRUhDtPIjbjfHHg>
  Backup
>   > software
program<http://groups.yahoo.com/gads?t=ms&k=Backup+software+program&w1=Medical+s\
oftware+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backup+\
software+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=1\
77&.sig=o_vSY5KI81jPG_EbBCvkfg>
Maintenance
>   > program
software<http://groups.yahoo.com/gads?t=ms&k=Maintenance+program+software&w1=Med\
ical+software+program&w2=Email+software+program&w3=Wedding+program+software&w4=B\
ackup+software+program&w5=Maintenance+program+software&w6=Cad+software+program&c\
=6&s=177&.sig=5ojBIMDbAVH8xjy4atsZmg>
Cad
>   > software
program<http://groups.yahoo.com/gads?t=ms&k=Cad+software+program&w1=Medical+soft\
ware+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backup+sof\
tware+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=177&\
.sig=NJ0JRSrHNG8BbrH--aDFRQ>
>   >  ------------------------------
>   > YAHOO! GROUPS LINKS
>   >
>   >
>   >    - Visit your group
"L3DT_users_group<http://groups.yahoo.com/group/L3DT_users_group>"
>   >    on the web.
>   >     - To unsubscribe from this group, send an email to:
>   >
L3DT_users_group-unsubscribe@yahoogroups.com<L3DT_users_group-unsubscribe@yahoog\
roups.com?subject=Unsubscribe>
>   >     - Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>   >    Service <http://docs.yahoo.com/info/terms/>.
>   >
>   >
>   >  ------------------------------
>   >
>
>
>
>   --
>   Gravity. It's not just a good idea, it's the law.
>
>
>   [Non-text portions of this message have been removed]
>
>
>
>
------------------------------------------------------------------------------
>   YAHOO! GROUPS LINKS
>
>     a..  Visit your group "L3DT_users_group" on the web.
>
>     b..  To unsubscribe from this group, send an email to:
>      L3DT_users_group-unsubscribe@yahoogroups.com
>
>     c..  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
>
>
>
------------------------------------------------------------------------------
>
>
>
> [Non-text portions of this message have been removed]
>

Hi Simeon,

> I think i misunderstood what you meant, I thought
> you meant including plugins in general, not plugin
> access or code into the sdk.

I want the SDK to be as powerful as possible, so that
other developers can make programs like L3DT without
having to write their own disk-paging,
plugin-handlers, garbage-collected memory, etc.
Basically, I will have achieved my goal if I can
re-build L3DT, replacing the core with the DLLs from
the SDK. This is nominally my goal for the next major
release of L3DT, to make the code neater and make
extensions easier.

> > As for the terrain renderer plugin, I've been
> > wanting to try my hand at this for a number of
> > years now.
>
> Well see you in another few years then ;)

Yup, probably.

> Sounds good, I've done a few dll plugins (heck
> Director is built around them, but they are called
> xtras). I did start to work on one for Gile[s],
> but as ever real-life got in the way. So hopefully
> i'm up to speed enough to get it working.

<understatement>
I think you'll be just fine.
</understatement>

I'll do my best to make it easy-to-learn for any
programmer familiar with OOP. The SDK will include
some nice step-by-step tutorials on making plugins or
apps, and there will also be complete project source
code for a couple of said plugins and apps.

I'd guess that an average programmer - familiar with
the workings of the SDK - would be able to belt-out a
file I/O plugin in about half-an-hour. That's about
how long it took me last night to write a plugin for
full load/save/mosaic support for the AMF file. I'm
sure I can make that more efficient too.

> One really nice project I did, that the L3DT sdk
> would have been really nice for was Scalextric and
> their new Sportworld product. I wrote the complete
3d
> editor, which they liked so much they've released it
> as a standalone product.

You are now my hero. Scalextric had a very big
following in my house when I was growing up. One
question...in your editor, could you put oil down on
the corners to make the cars do power-slides? If not,
I think that would be good for v2.0!

> I'm currently working on a train simulator, which
> i'd love to use L3DT to produce the terrain
> environment, but with a duration of less than 3
> weeks, i have no time to pursue it. Maybe in a
> version 2.

Sheesh. Another one of my guilty pleasures. I got
myself hooked on Railroad Tycoon 3 last year, and it
took me months to kick the habit. Oh the shame!

> I've also had some success using L3DT output with
> Director, basic stuff at first like loading the
> hieghtmap data. But more recently using Glex, an
xtra
> i've written with a collegue that intercepts the
> opengl code path of sw3d allowing us to add new
> abilities, such as shaders, which I used with the
> alpha maps for terrain splatting.

Whoa, in my country you can still be burned at the
stake for voodoo like that. Be careful.

Cheers,
Aaron.




--- Noisecrime_PIPEX <atic73@...> wrote:

>
>
>
> ----- Original Message -----
> From: "Aaron Torpy" <aaron_torpy@...>
>
>
> > Hmmm....I'm not sure I'll be putting *everything*
> into
> > the SDK. I really envisioned the SDK to be an easy
> > tool with which other people can write file
> > converters, and build their own map-handling
> > applications.
>
> I think i misunderstood what you meant, I thought
> you meant including
> plugins in general, not plugin access or code into
> the sdk.
>
>
> >  As for the
> > terrain renderer plugin, I've been wanting to try
> my
> > hand at this for a number of years now.
>
> Well see you in another few years then ;)
>
>
> > So long as you're using C++, there is hardly any
> > setup. You only need to include 'zeolite.lib' in
> your
> > linking list, add a few .cpp and .h files to your
> > workspace, and then throw-in a couple of
> '#includes'
> > and one 'extern' statement at the top any cpp
> files
> > that use the SDK.
>
> Sounds good, I've done a few dll plugins (heck
> Director is built around
> them, but they are called xtras). I did start to
> work on one for Gile[s],
> but as ever real-life got in the way. So hopefully
> i'm up to speed enough to
> get it working.
>
>
> > I wish you the best of luck, and congratulations
> on
> > your excellent SW3D demos (I was just browsing
> your
> > website). I was rather blown away by the
> > shadow-mapping, water-reflection and
> texture-splatting
> > demos. Really outstanding!
>
> Thanks, those are getting pretty old now, in fact
> much of my more recent
> work isn't even online.
>
> One really nice project I did, that the L3DT sdk
> would have been really nice
> for was Scalextric and their new Sportworld product.
> I wrote the complete 3d
> editor, which they liked so much they've released it
> as a standalone
> product. (
>
http://www.slotforum.com/forums/index.php?s=7e5384810bf0d8f2115151d974c7fb8b&sho\
wtopic=10876
> )
>
> I'm currently working on a train simulator, which
> i'd love to use L3DT to
> produce the terrain environment, but with a duration
> of less than 3 weeks, i
> have no time to pursue it. Maybe in a version 2.
>
> I've also had some success using L3DT output with
> Director, basic stuff at
> first like loading the hieghtmap data. But more
> recently using Glex, an xtra
> i've written with a collegue that intercepts the
> opengl code path of sw3d
> allowing us to add new abilities, such as shaders,
> which I used with the
> alpha maps for terrain splatting.
>
> Sadly I ran out time to get it working at any level
> to show, but its still
> on the backburner.
>
>
> Noisecrime 2005
> http://www.noisecrime.com
>
>

Hi Ralf,

Yup, I think I could write wrappers in Delphi (Lord
knows I need the practice). I’ll probably do the C++
release first, get some feedback and make appropriate
revisions, and then write the equivalent Delphi code.

<DREAM>
If I’m lucky, a Delphi programmer with a lazy
afternoon to spare might translate the C++ wrapper
code before I’ve even remembered the proper syntax for
Pascal if/then/else statements. If I’m really lucky,
the same thing might happen for VB.
</DREAM>

> Speaking of which, do you have any short- or
mid-term
> plans for porting it to other operating systems?

I'd say that's more of a long-term goal. However, if
there is a big (!) demand from the users (or potential
users), then I will make it a higher priority. Even
so, it would probably take many months to get
everything working without the Microsoft Foundation
Classes. My non-windows experience is limited to about
a thousand lines of ANSI C on a HP-UX box, so I might
have a bit of learnin’ to do.

Cheers,
Aaron.

--- yahoo at ralf-lehmann dot de
<yahoo@...> wrote:

> Hey!
>
> > Great! I love it when decisions are unanimous.
>
> Me too! :) I just wonder if it would be too hard to
> provide a Delphi
> "version" as well. You know, I'm "learning" C++ for
> a while now but I'm
> wondering if having a number of wrappers wouldn't
> improve the number of
> contributions significantly. At least
> quantitatively. ;)
>
> On the Windows side of things I'd prefer the DLL way
> as well...
>
> Speaking of which, do you have any short- or
> mid-term plans for porting it
> to other operating systems?
>
> Curiously,
>
> Ralf. :)
>
>

Hey!

> Great! I love it when decisions are unanimous.

Me too! :) I just wonder if it would be too hard to provide a Delphi
"version" as well. You know, I'm "learning" C++ for a while now but I'm
wondering if having a number of wrappers wouldn't improve the number of
contributions significantly. At least quantitatively. ;)

On the Windows side of things I'd prefer the DLL way as well...

Speaking of which, do you have any short- or mid-term plans for porting it
to other operating systems?

Curiously,

Ralf. :)

Oh, then my source was wrong. I was told that it was faster, my mistake.
  -Mark
  p.s. Thanks for correcting me.

  On 11/8/05, Admin Kiraya <kiraya@...> wrote:
>
> sorry but java is not faster than c++.
> it's only clearer,easiest and portable (because have virtual machine).
>
> ----- Original Message -----
> From: mark troutt
> To: L3DT_users_group@yahoogroups.com
> Sent: Tuesday, November 08, 2005 1:37 PM
> Subject: Re: [L3DT users' group] Re: SDK progress report
>
>
> Well, when I say "besides maybe java" I don't mean to imply that I've ever
> used it. All I know is that it can be more portable to other operating
> systems and that it's supposed to be faster. I've never looked into
> actually
> coding in it :) . Sorry for the confusion. I was just saying that I
> wouldn't
> ever consider vb or vb.net <http://vb.net/> <http://vb.net> for my games
> but I use c++ and
> would consider java, maybe.
> -Mark
>
> On 11/7/05, Aaron Torpy <aaron_torpy@...> wrote:
> >
> > Hi Mark,
> >
> > > (besides maybe java...)
> >
> > I'm terribly ignorant of Java, but from what little I
> > have read, it seems that it can be a bit of a pain in
> > importing 'non-managed' functions from DLL. Can you
> > shed any light on this unsupported assertion?
> >
> > > now you have votes of 5 out of 5 for most things :)
> >
> > Great! I love it when decisions are unanimous.
> >
> > Cheers,
> > Aaron.
> >
> > --- mark troutt <marktroutt@...> wrote:
> >
> > > Wow, I missed so much stuff in one day. Well Aaron
> > > for your answers:
> > > 1. I think everything I want/need has already been
> > > included or mentioned.
> > > 2. For standard I think that I'm all set. All I
> > > really need is the
> > > ability to import it directly into my format.
> > > Currently I've been
> > > having to use a script I made for 3ds max to turn
> > > heightmaps into
> > > terrain so I can export it from there.
> > > 3. C++ all the way. VB is too slow for me and I
> > > have gotten too
> > > situated with C++ to use anything else (besides
> > > maybe java...).
> > > 4. I'd rather use a dll. Makes it easier on me.
> > > 5. No unicode. I don't use it and I'm not planning
> > > to anytime soon
> > > (not within the next 40 years) so it isn't
> > > neccesary.
> > >
> > > So that is my two cents and now you have votes of 5
> > > out of 5 for most
> > > things :) .
> > >
> > > -Mark
> > >
> > > On 11/7/05, Noisecrime_PIPEX <atic73@...>
> > > wrote:
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Aaron Torpy" <aaron_torpy@...>
> > > >
> > > >
> > > > > Hmmm....I'm not sure I'll be putting
> > > *everything* into
> > > > > the SDK. I really envisioned the SDK to be an
> > > easy
> > > > > tool with which other people can write file
> > > > > converters, and build their own map-handling
> > > > > applications.
> > > >
> > > > I think i misunderstood what you meant, I
> > > thought you meant including
> > > > plugins in general, not plugin access or code
> > > into the sdk.
> > > >
> > > >
> > > > > As for the
> > > > > terrain renderer plugin, I've been wanting to
> > > try my
> > > > > hand at this for a number of years now.
> > > >
> > > > Well see you in another few years then ;)
> > > >
> > > >
> > > > > So long as you're using C++, there is hardly
> > > any
> > > > > setup. You only need to include 'zeolite.lib'
> > > in your
> > > > > linking list, add a few .cpp and .h files to
> > > your
> > > > > workspace, and then throw-in a couple of
> > > '#includes'
> > > > > and one 'extern' statement at the top any cpp
> > > files
> > > > > that use the SDK.
> > > >
> > > > Sounds good, I've done a few dll plugins (heck
> > > Director is built around
> > > > them, but they are called xtras). I did start to
> > > work on one for Gile[s],
> > > > but as ever real-life got in the way. So
> > > hopefully i'm up to speed enough
> > > > to
> > > > get it working.
> > > >
> > > >
> > > > > I wish you the best of luck, and
> > > congratulations on
> > > > > your excellent SW3D demos (I was just browsing
> > > your
> > > > > website). I was rather blown away by the
> > > > > shadow-mapping, water-reflection and
> > > texture-splatting
> > > > > demos. Really outstanding!
> > > >
> > > > Thanks, those are getting pretty old now, in
> > > fact much of my more recent
> > > > work isn't even online.
> > > >
> > > > One really nice project I did, that the L3DT sdk
> > > would have been really
> > > > nice
> > > > for was Scalextric and their new Sportworld
> > > product. I wrote the complete
> > > > 3d
> > > > editor, which they liked so much they've
> > > released it as a standalone
> > > > product. (
> > > >
> > >
> >
> >
>
http://www.slotforum.com/forums/index.php?s=7e5384810bf0d8f2115151d974c7fb8b&sho\
wtopic=10876
> > > > )
> > > >
> > > > I'm currently working on a train simulator,
> > > which i'd love to use L3DT to
> > > > produce the terrain environment, but with a
> > > duration of less than 3 weeks,
> > > > i
> > > > have no time to pursue it. Maybe in a version 2.
> > > >
> > > > I've also had some success using L3DT output
> > > with Director, basic stuff at
> > > > first like loading the hieghtmap data. But more
> > > recently using Glex, an
> > > > xtra
> > > > i've written with a collegue that intercepts the
> > > opengl code path of sw3d
> > > > allowing us to add new abilities, such as
> > > shaders, which I used with the
> > > > alpha maps for terrain splatting.
> > > >
> > > > Sadly I ran out time to get it working at any
> > > level to show, but its still
> > > > on the backburner.
> > > >
> > > >
> > > > Noisecrime 2005
> > > > http://www.noisecrime.com
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > YAHOO! GROUPS LINKS
> > > >
> > > >
> > > > Visit your group "L3DT_users_group" on the web.
> > > >
> > > > To unsubscribe from this group, send an email
> > > to:
> > > > L3DT_users_group-unsubscribe@yahoogroups.com
> > > >
> > > > Your use of Yahoo! Groups is subject to the
> > > Yahoo! Terms of Service.
> > > >
> > > > ________________________________
> > > >
> > > >
> > >
> > >
> > > --
> > > Gravity. It's not just a good idea, it's the law.
> > >
> >
> >
> >
> > SPONSORED LINKS
> > Medical software program<
>
http://groups.yahoo.com/gads?t=ms&k=Medical+software+program&w1=Medical+software\
+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backup+softwar\
e+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=177&.sig\
=H4YaistW4xiEohGSob9qig>
> Email
> > software program<
>
http://groups.yahoo.com/gads?t=ms&k=Email+software+program&w1=Medical+software+p\
rogram&w2=Email+software+program&w3=Wedding+program+software&w4=Backup+software+\
program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=177&.sig=P\
dYAtHlttFUdWUXdTCGCIg>
> Wedding
> > program software<
>
http://groups.yahoo.com/gads?t=ms&k=Wedding+program+software&w1=Medical+software\
+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backup+softwar\
e+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=177&.sig\
=ozUUVqwSRUhDtPIjbjfHHg>
> Backup
> > software program<
>
http://groups.yahoo.com/gads?t=ms&k=Backup+software+program&w1=Medical+software+\
program&w2=Email+software+program&w3=Wedding+program+software&w4=Backup+software\
+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=177&.sig=\
o_vSY5KI81jPG_EbBCvkfg>
> Maintenance
> > program software<
>
http://groups.yahoo.com/gads?t=ms&k=Maintenance+program+software&w1=Medical+soft\
ware+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backup+sof\
tware+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=177&\
.sig=5ojBIMDbAVH8xjy4atsZmg>
> Cad
> > software program<
>
http://groups.yahoo.com/gads?t=ms&k=Cad+software+program&w1=Medical+software+pro\
gram&w2=Email+software+program&w3=Wedding+program+software&w4=Backup+software+pr\
ogram&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=177&.sig=NJ0\
JRSrHNG8BbrH--aDFRQ
> >
> > ------------------------------
> > YAHOO! GROUPS LINKS
> >
> >
> > - Visit your group "L3DT_users_group<
> http://groups.yahoo.com/group/L3DT_users_group>"
> > on the web.
> > - To unsubscribe from this group, send an email to:
> > L3DT_users_group-unsubscribe@yahoogroups.com<
> L3DT_users_group-unsubscribe@yahoogroups.com?subject=Unsubscribe>
> > - Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> > Service <http://docs.yahoo.com/info/terms/>.
> >
> >
> > ------------------------------
> >
>
>
>
> --
> Gravity. It's not just a good idea, it's the law.
>
>
> [Non-text portions of this message have been removed]
>
>
>
>
> ------------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
> a.. Visit your group "L3DT_users_group" on the web.
>
> b.. To unsubscribe from this group, send an email to:
> L3DT_users_group-unsubscribe@yahoogroups.com
>
> c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> [Non-text portions of this message have been removed]
>
>
>  ------------------------------
> YAHOO! GROUPS LINKS
>
>
>    - Visit your group
"L3DT_users_group<http://groups.yahoo.com/group/L3DT_users_group>"
>    on the web.
>     - To unsubscribe from this group, send an email to:
>   
L3DT_users_group-unsubscribe@yahoogroups.com<L3DT_users_group-unsubscribe@yahoog\
roups.com?subject=Unsubscribe>
>     - Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>    Service <http://docs.yahoo.com/info/terms/>.
>
>
>  ------------------------------
>



--
Gravity. It's not just a good idea, it's the law.


[Non-text portions of this message have been removed]

sorry but java is not faster than c++.
it's only clearer,easiest and portable (because have virtual machine).

   ----- Original Message -----
   From: mark troutt
   To: L3DT_users_group@yahoogroups.com
   Sent: Tuesday, November 08, 2005 1:37 PM
   Subject: Re: [L3DT users' group] Re: SDK progress report


   Well, when I say "besides maybe java" I don't mean to imply that I've ever
   used it. All I know is that it can be more portable to other operating
   systems and that it's supposed to be faster. I've never looked into actually
   coding in it :) . Sorry for the confusion. I was just saying that I wouldn't
   ever consider vb or vb.net <http://vb.net> for my games but I use c++ and
   would consider java, maybe.
   -Mark

   On 11/7/05, Aaron Torpy <aaron_torpy@...> wrote:
   >
   > Hi Mark,
   >
   > > (besides maybe java...)
   >
   > I'm terribly ignorant of Java, but from what little I
   > have read, it seems that it can be a bit of a pain in
   > importing 'non-managed' functions from DLL. Can you
   > shed any light on this unsupported assertion?
   >
   > > now you have votes of 5 out of 5 for most things :)
   >
   > Great! I love it when decisions are unanimous.
   >
   > Cheers,
   > Aaron.
   >
   > --- mark troutt <marktroutt@...> wrote:
   >
   > > Wow, I missed so much stuff in one day. Well Aaron
   > > for your answers:
   > > 1. I think everything I want/need has already been
   > > included or mentioned.
   > > 2. For standard I think that I'm all set. All I
   > > really need is the
   > > ability to import it directly into my format.
   > > Currently I've been
   > > having to use a script I made for 3ds max to turn
   > > heightmaps into
   > > terrain so I can export it from there.
   > > 3. C++ all the way. VB is too slow for me and I
   > > have gotten too
   > > situated with C++ to use anything else (besides
   > > maybe java...).
   > > 4. I'd rather use a dll. Makes it easier on me.
   > > 5. No unicode. I don't use it and I'm not planning
   > > to anytime soon
   > > (not within the next 40 years) so it isn't
   > > neccesary.
   > >
   > > So that is my two cents and now you have votes of 5
   > > out of 5 for most
   > > things :) .
   > >
   > > -Mark
   > >
   > > On 11/7/05, Noisecrime_PIPEX <atic73@...>
   > > wrote:
   > > >
   > > >
   > > > ----- Original Message -----
   > > > From: "Aaron Torpy" <aaron_torpy@...>
   > > >
   > > >
   > > > > Hmmm....I'm not sure I'll be putting
   > > *everything* into
   > > > > the SDK. I really envisioned the SDK to be an
   > > easy
   > > > > tool with which other people can write file
   > > > > converters, and build their own map-handling
   > > > > applications.
   > > >
   > > > I think i misunderstood what you meant, I
   > > thought you meant including
   > > > plugins in general, not plugin access or code
   > > into the sdk.
   > > >
   > > >
   > > > > As for the
   > > > > terrain renderer plugin, I've been wanting to
   > > try my
   > > > > hand at this for a number of years now.
   > > >
   > > > Well see you in another few years then ;)
   > > >
   > > >
   > > > > So long as you're using C++, there is hardly
   > > any
   > > > > setup. You only need to include 'zeolite.lib'
   > > in your
   > > > > linking list, add a few .cpp and .h files to
   > > your
   > > > > workspace, and then throw-in a couple of
   > > '#includes'
   > > > > and one 'extern' statement at the top any cpp
   > > files
   > > > > that use the SDK.
   > > >
   > > > Sounds good, I've done a few dll plugins (heck
   > > Director is built around
   > > > them, but they are called xtras). I did start to
   > > work on one for Gile[s],
   > > > but as ever real-life got in the way. So
   > > hopefully i'm up to speed enough
   > > > to
   > > > get it working.
   > > >
   > > >
   > > > > I wish you the best of luck, and
   > > congratulations on
   > > > > your excellent SW3D demos (I was just browsing
   > > your
   > > > > website). I was rather blown away by the
   > > > > shadow-mapping, water-reflection and
   > > texture-splatting
   > > > > demos. Really outstanding!
   > > >
   > > > Thanks, those are getting pretty old now, in
   > > fact much of my more recent
   > > > work isn't even online.
   > > >
   > > > One really nice project I did, that the L3DT sdk
   > > would have been really
   > > > nice
   > > > for was Scalextric and their new Sportworld
   > > product. I wrote the complete
   > > > 3d
   > > > editor, which they liked so much they've
   > > released it as a standalone
   > > > product. (
   > > >
   > >
   >
   >
http://www.slotforum.com/forums/index.php?s=7e5384810bf0d8f2115151d974c7fb8b&sho\
wtopic=10876
   > > > )
   > > >
   > > > I'm currently working on a train simulator,
   > > which i'd love to use L3DT to
   > > > produce the terrain environment, but with a
   > > duration of less than 3 weeks,
   > > > i
   > > > have no time to pursue it. Maybe in a version 2.
   > > >
   > > > I've also had some success using L3DT output
   > > with Director, basic stuff at
   > > > first like loading the hieghtmap data. But more
   > > recently using Glex, an
   > > > xtra
   > > > i've written with a collegue that intercepts the
   > > opengl code path of sw3d
   > > > allowing us to add new abilities, such as
   > > shaders, which I used with the
   > > > alpha maps for terrain splatting.
   > > >
   > > > Sadly I ran out time to get it working at any
   > > level to show, but its still
   > > > on the backburner.
   > > >
   > > >
   > > > Noisecrime 2005
   > > > http://www.noisecrime.com
   > > >
   > > >
   > > >
   > > > ________________________________
   > > > YAHOO! GROUPS LINKS
   > > >
   > > >
   > > > Visit your group "L3DT_users_group" on the web.
   > > >
   > > > To unsubscribe from this group, send an email
   > > to:
   > > > L3DT_users_group-unsubscribe@yahoogroups.com
   > > >
   > > > Your use of Yahoo! Groups is subject to the
   > > Yahoo! Terms of Service.
   > > >
   > > > ________________________________
   > > >
   > > >
   > >
   > >
   > > --
   > > Gravity. It's not just a good idea, it's the law.
   > >
   >
   >
   >
   > SPONSORED LINKS
   >   Medical software
program<http://groups.yahoo.com/gads?t=ms&k=Medical+software+program&w1=Medical+\
software+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backup\
+software+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=\
177&.sig=H4YaistW4xiEohGSob9qig> Email
   > software
program<http://groups.yahoo.com/gads?t=ms&k=Email+software+program&w1=Medical+so\
ftware+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backup+s\
oftware+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=17\
7&.sig=PdYAtHlttFUdWUXdTCGCIg> Wedding
   > program
software<http://groups.yahoo.com/gads?t=ms&k=Wedding+program+software&w1=Medical\
+software+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backu\
p+software+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s\
=177&.sig=ozUUVqwSRUhDtPIjbjfHHg>  Backup
   > software
program<http://groups.yahoo.com/gads?t=ms&k=Backup+software+program&w1=Medical+s\
oftware+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backup+\
software+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=1\
77&.sig=o_vSY5KI81jPG_EbBCvkfg> Maintenance
   > program
software<http://groups.yahoo.com/gads?t=ms&k=Maintenance+program+software&w1=Med\
ical+software+program&w2=Email+software+program&w3=Wedding+program+software&w4=B\
ackup+software+program&w5=Maintenance+program+software&w6=Cad+software+program&c\
=6&s=177&.sig=5ojBIMDbAVH8xjy4atsZmg> Cad
   > software
program<http://groups.yahoo.com/gads?t=ms&k=Cad+software+program&w1=Medical+soft\
ware+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backup+sof\
tware+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=177&\
.sig=NJ0JRSrHNG8BbrH--aDFRQ>
   >  ------------------------------
   > YAHOO! GROUPS LINKS
   >
   >
   >    - Visit your group
"L3DT_users_group<http://groups.yahoo.com/group/L3DT_users_group>"
   >    on the web.
   >     - To unsubscribe from this group, send an email to:
   >   
L3DT_users_group-unsubscribe@yahoogroups.com<L3DT_users_group-unsubscribe@yahoog\
roups.com?subject=Unsubscribe>
   >     - Your use of Yahoo! Groups is subject to the Yahoo! Terms of
   >    Service <http://docs.yahoo.com/info/terms/>.
   >
   >
   >  ------------------------------
   >



   --
   Gravity. It's not just a good idea, it's the law.


   [Non-text portions of this message have been removed]



------------------------------------------------------------------------------
   YAHOO! GROUPS LINKS

     a..  Visit your group "L3DT_users_group" on the web.

     b..  To unsubscribe from this group, send an email to:
      L3DT_users_group-unsubscribe@yahoogroups.com

     c..  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


------------------------------------------------------------------------------



[Non-text portions of this message have been removed]

Well, when I say "besides maybe java" I don't mean to imply that I've ever
used it. All I know is that it can be more portable to other operating
systems and that it's supposed to be faster. I've never looked into actually
coding in it :) . Sorry for the confusion. I was just saying that I wouldn't
ever consider vb or vb.net <http://vb.net> for my games but I use c++ and
would consider java, maybe.
  -Mark

  On 11/7/05, Aaron Torpy <aaron_torpy@...> wrote:
>
> Hi Mark,
>
> > (besides maybe java...)
>
> I'm terribly ignorant of Java, but from what little I
> have read, it seems that it can be a bit of a pain in
> importing 'non-managed' functions from DLL. Can you
> shed any light on this unsupported assertion?
>
> > now you have votes of 5 out of 5 for most things :)
>
> Great! I love it when decisions are unanimous.
>
> Cheers,
> Aaron.
>
> --- mark troutt <marktroutt@...> wrote:
>
> > Wow, I missed so much stuff in one day. Well Aaron
> > for your answers:
> > 1. I think everything I want/need has already been
> > included or mentioned.
> > 2. For standard I think that I'm all set. All I
> > really need is the
> > ability to import it directly into my format.
> > Currently I've been
> > having to use a script I made for 3ds max to turn
> > heightmaps into
> > terrain so I can export it from there.
> > 3. C++ all the way. VB is too slow for me and I
> > have gotten too
> > situated with C++ to use anything else (besides
> > maybe java...).
> > 4. I'd rather use a dll. Makes it easier on me.
> > 5. No unicode. I don't use it and I'm not planning
> > to anytime soon
> > (not within the next 40 years) so it isn't
> > neccesary.
> >
> > So that is my two cents and now you have votes of 5
> > out of 5 for most
> > things :) .
> >
> > -Mark
> >
> > On 11/7/05, Noisecrime_PIPEX <atic73@...>
> > wrote:
> > >
> > >
> > > ----- Original Message -----
> > > From: "Aaron Torpy" <aaron_torpy@...>
> > >
> > >
> > > > Hmmm....I'm not sure I'll be putting
> > *everything* into
> > > > the SDK. I really envisioned the SDK to be an
> > easy
> > > > tool with which other people can write file
> > > > converters, and build their own map-handling
> > > > applications.
> > >
> > > I think i misunderstood what you meant, I
> > thought you meant including
> > > plugins in general, not plugin access or code
> > into the sdk.
> > >
> > >
> > > > As for the
> > > > terrain renderer plugin, I've been wanting to
> > try my
> > > > hand at this for a number of years now.
> > >
> > > Well see you in another few years then ;)
> > >
> > >
> > > > So long as you're using C++, there is hardly
> > any
> > > > setup. You only need to include 'zeolite.lib'
> > in your
> > > > linking list, add a few .cpp and .h files to
> > your
> > > > workspace, and then throw-in a couple of
> > '#includes'
> > > > and one 'extern' statement at the top any cpp
> > files
> > > > that use the SDK.
> > >
> > > Sounds good, I've done a few dll plugins (heck
> > Director is built around
> > > them, but they are called xtras). I did start to
> > work on one for Gile[s],
> > > but as ever real-life got in the way. So
> > hopefully i'm up to speed enough
> > > to
> > > get it working.
> > >
> > >
> > > > I wish you the best of luck, and
> > congratulations on
> > > > your excellent SW3D demos (I was just browsing
> > your
> > > > website). I was rather blown away by the
> > > > shadow-mapping, water-reflection and
> > texture-splatting
> > > > demos. Really outstanding!
> > >
> > > Thanks, those are getting pretty old now, in
> > fact much of my more recent
> > > work isn't even online.
> > >
> > > One really nice project I did, that the L3DT sdk
> > would have been really
> > > nice
> > > for was Scalextric and their new Sportworld
> > product. I wrote the complete
> > > 3d
> > > editor, which they liked so much they've
> > released it as a standalone
> > > product. (
> > >
> >
>
>
http://www.slotforum.com/forums/index.php?s=7e5384810bf0d8f2115151d974c7fb8b&sho\
wtopic=10876
> > > )
> > >
> > > I'm currently working on a train simulator,
> > which i'd love to use L3DT to
> > > produce the terrain environment, but with a
> > duration of less than 3 weeks,
> > > i
> > > have no time to pursue it. Maybe in a version 2.
> > >
> > > I've also had some success using L3DT output
> > with Director, basic stuff at
> > > first like loading the hieghtmap data. But more
> > recently using Glex, an
> > > xtra
> > > i've written with a collegue that intercepts the
> > opengl code path of sw3d
> > > allowing us to add new abilities, such as
> > shaders, which I used with the
> > > alpha maps for terrain splatting.
> > >
> > > Sadly I ran out time to get it working at any
> > level to show, but its still
> > > on the backburner.
> > >
> > >
> > > Noisecrime 2005
> > > http://www.noisecrime.com
> > >
> > >
> > >
> > > ________________________________
> > > YAHOO! GROUPS LINKS
> > >
> > >
> > > Visit your group "L3DT_users_group" on the web.
> > >
> > > To unsubscribe from this group, send an email
> > to:
> > > L3DT_users_group-unsubscribe@yahoogroups.com
> > >
> > > Your use of Yahoo! Groups is subject to the
> > Yahoo! Terms of Service.
> > >
> > > ________________________________
> > >
> > >
> >
> >
> > --
> > Gravity. It's not just a good idea, it's the law.
> >
>
>
>
> SPONSORED LINKS
>   Medical software
program<http://groups.yahoo.com/gads?t=ms&k=Medical+software+program&w1=Medical+\
software+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backup\
+software+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=\
177&.sig=H4YaistW4xiEohGSob9qig> Email
> software
program<http://groups.yahoo.com/gads?t=ms&k=Email+software+program&w1=Medical+so\
ftware+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backup+s\
oftware+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=17\
7&.sig=PdYAtHlttFUdWUXdTCGCIg> Wedding
> program
software<http://groups.yahoo.com/gads?t=ms&k=Wedding+program+software&w1=Medical\
+software+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backu\
p+software+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s\
=177&.sig=ozUUVqwSRUhDtPIjbjfHHg>  Backup
> software
program<http://groups.yahoo.com/gads?t=ms&k=Backup+software+program&w1=Medical+s\
oftware+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backup+\
software+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=1\
77&.sig=o_vSY5KI81jPG_EbBCvkfg> Maintenance
> program
software<http://groups.yahoo.com/gads?t=ms&k=Maintenance+program+software&w1=Med\
ical+software+program&w2=Email+software+program&w3=Wedding+program+software&w4=B\
ackup+software+program&w5=Maintenance+program+software&w6=Cad+software+program&c\
=6&s=177&.sig=5ojBIMDbAVH8xjy4atsZmg> Cad
> software
program<http://groups.yahoo.com/gads?t=ms&k=Cad+software+program&w1=Medical+soft\
ware+program&w2=Email+software+program&w3=Wedding+program+software&w4=Backup+sof\
tware+program&w5=Maintenance+program+software&w6=Cad+software+program&c=6&s=177&\
.sig=NJ0JRSrHNG8BbrH--aDFRQ>
>  ------------------------------
> YAHOO! GROUPS LINKS
>
>
>    - Visit your group
"L3DT_users_group<http://groups.yahoo.com/group/L3DT_users_group>"
>    on the web.
>     - To unsubscribe from this group, send an email to:
>   
L3DT_users_group-unsubscribe@yahoogroups.com<L3DT_users_group-unsubscribe@yahoog\
roups.com?subject=Unsubscribe>
>     - Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>    Service <http://docs.yahoo.com/info/terms/>.
>
>
>  ------------------------------
>



--
Gravity. It's not just a good idea, it's the law.


[Non-text portions of this message have been removed]

Hi Mark,

> (besides maybe java...)

I'm terribly ignorant of Java, but from what little I
have read, it seems that it can be a bit of a pain in
importing 'non-managed' functions from DLL. Can you
shed any light on this unsupported assertion?

> now you have votes of 5 out of 5 for most things :)

Great! I love it when decisions are unanimous.

Cheers,
Aaron.

--- mark troutt <marktroutt@...> wrote:

> Wow, I missed so much stuff in one day.  Well Aaron
> for your answers:
> 1. I think everything I want/need has already been
> included or mentioned.
> 2. For standard I think that I'm all set.  All I
> really need is the
> ability to import it directly into my format.
> Currently I've been
> having to use a script I made for 3ds max to turn
> heightmaps into
> terrain so I can export it from there.
> 3. C++ all the way.  VB is too slow for me and I
> have gotten too
> situated with C++ to use anything else (besides
> maybe java...).
> 4. I'd rather use a dll.  Makes it easier on me.
> 5. No unicode.  I don't use it and I'm not planning
> to anytime soon
> (not within the next 40 years) so it isn't
> neccesary.
>
> So that is my two cents and now you have votes of 5
> out of 5 for most
> things :) .
>
> -Mark
>
> On 11/7/05, Noisecrime_PIPEX <atic73@...>
> wrote:
> >
> >
> >   ----- Original Message -----
> >   From: "Aaron Torpy" <aaron_torpy@...>
> >
> >
> >   > Hmmm....I'm not sure I'll be putting
> *everything* into
> >   > the SDK. I really envisioned the SDK to be an
> easy
> >   > tool with which other people can write file
> >   > converters, and build their own map-handling
> >   > applications.
> >
> >   I think i misunderstood what you meant, I
> thought you meant including
> >   plugins in general, not plugin access or code
> into the sdk.
> >
> >
> >   >  As for the
> >   > terrain renderer plugin, I've been wanting to
> try my
> >   > hand at this for a number of years now.
> >
> >   Well see you in another few years then ;)
> >
> >
> >   > So long as you're using C++, there is hardly
> any
> >   > setup. You only need to include 'zeolite.lib'
> in your
> >   > linking list, add a few .cpp and .h files to
> your
> >   > workspace, and then throw-in a couple of
> '#includes'
> >   > and one 'extern' statement at the top any cpp
> files
> >   > that use the SDK.
> >
> >   Sounds good, I've done a few dll plugins (heck
> Director is built around
> >   them, but they are called xtras). I did start to
> work on one for Gile[s],
> >   but as ever real-life got in the way. So
> hopefully i'm up to speed enough
> > to
> >   get it working.
> >
> >
> >   > I wish you the best of luck, and
> congratulations on
> >   > your excellent SW3D demos (I was just browsing
> your
> >   > website). I was rather blown away by the
> >   > shadow-mapping, water-reflection and
> texture-splatting
> >   > demos. Really outstanding!
> >
> >   Thanks, those are getting pretty old now, in
> fact much of my more recent
> >   work isn't even online.
> >
> >   One really nice project I did, that the L3DT sdk
> would have been really
> > nice
> >   for was Scalextric and their new Sportworld
> product. I wrote the complete
> > 3d
> >   editor, which they liked so much they've
> released it as a standalone
> >   product. (
> >
>
http://www.slotforum.com/forums/index.php?s=7e5384810bf0d8f2115151d974c7fb8b&sho\
wtopic=10876
> > )
> >
> >   I'm currently working on a train simulator,
> which i'd love to use L3DT to
> >   produce the terrain environment, but with a
> duration of less than 3 weeks,
> > i
> >   have no time to pursue it. Maybe in a version 2.
> >
> >   I've also had some success using L3DT output
> with Director, basic stuff at
> >   first like loading the hieghtmap data. But more
> recently using Glex, an
> > xtra
> >   i've written with a collegue that intercepts the
> opengl code path of sw3d
> >   allowing us to add new abilities, such as
> shaders, which I used with the
> >   alpha maps for terrain splatting.
> >
> >   Sadly I ran out time to get it working at any
> level to show, but its still
> >   on the backburner.
> >
> >
> >   Noisecrime 2005
> >  http://www.noisecrime.com
> >
> >
> >
> >  ________________________________
> >  YAHOO! GROUPS LINKS
> >
> >
> >  Visit your group "L3DT_users_group" on the web.
> >
> >   To unsubscribe from this group, send an email
> to:
> >  L3DT_users_group-unsubscribe@yahoogroups.com
> >
> >   Your use of Yahoo! Groups is subject to the
> Yahoo! Terms of Service.
> >
> >  ________________________________
> >
> >
>
>
> --
> Gravity.  It's not just a good idea, it's the law.
>

I'm learning both C++ and C#, primarily C# at the moment. But if it would be
too difficult to make the C# one, I wouldn't mind if you didn't pursue it.
Your time is probably better spent elsewhere.

One thing though, it seems the large percent of the guys at TV3D (where I
first heard about L3DT) use VB6 and VB.net.



3) What programming language(s) do you use? (I've written nice
wrappers for C/C++, but that's it so far).







[Non-text portions of this message have been removed]

This sounds great.  And I think my answers will be consistent with the
others I have seen.

At this point I can't think of anything else you need to add beyond what
you mentioned.  C/C++ please.  Is there anything else to code in? (well
I guess C# and Java but I don't code in those unless I have to).
Unicode gives me a headache.  DLL is fine with me.

Looking forward to it.  Hope I can find the time to play around with it
when it's available for beta.

Wow, I missed so much stuff in one day.  Well Aaron for your answers:
1. I think everything I want/need has already been included or mentioned.
2. For standard I think that I'm all set.  All I really need is the
ability to import it directly into my format.  Currently I've been
having to use a script I made for 3ds max to turn heightmaps into
terrain so I can export it from there.
3. C++ all the way.  VB is too slow for me and I have gotten too
situated with C++ to use anything else (besides maybe java...).
4. I'd rather use a dll.  Makes it easier on me.
5. No unicode.  I don't use it and I'm not planning to anytime soon
(not within the next 40 years) so it isn't neccesary.

So that is my two cents and now you have votes of 5 out of 5 for most
things :) .

-Mark

On 11/7/05, Noisecrime_PIPEX <atic73@...> wrote:
>
>
>   ----- Original Message -----
>   From: "Aaron Torpy" <aaron_torpy@...>
>
>
>   > Hmmm....I'm not sure I'll be putting *everything* into
>   > the SDK. I really envisioned the SDK to be an easy
>   > tool with which other people can write file
>   > converters, and build their own map-handling
>   > applications.
>
>   I think i misunderstood what you meant, I thought you meant including
>   plugins in general, not plugin access or code into the sdk.
>
>
>   >  As for the
>   > terrain renderer plugin, I've been wanting to try my
>   > hand at this for a number of years now.
>
>   Well see you in another few years then ;)
>
>
>   > So long as you're using C++, there is hardly any
>   > setup. You only need to include 'zeolite.lib' in your
>   > linking list, add a few .cpp and .h files to your
>   > workspace, and then throw-in a couple of '#includes'
>   > and one 'extern' statement at the top any cpp files
>   > that use the SDK.
>
>   Sounds good, I've done a few dll plugins (heck Director is built around
>   them, but they are called xtras). I did start to work on one for Gile[s],
>   but as ever real-life got in the way. So hopefully i'm up to speed enough
> to
>   get it working.
>
>
>   > I wish you the best of luck, and congratulations on
>   > your excellent SW3D demos (I was just browsing your
>   > website). I was rather blown away by the
>   > shadow-mapping, water-reflection and texture-splatting
>   > demos. Really outstanding!
>
>   Thanks, those are getting pretty old now, in fact much of my more recent
>   work isn't even online.
>
>   One really nice project I did, that the L3DT sdk would have been really
> nice
>   for was Scalextric and their new Sportworld product. I wrote the complete
> 3d
>   editor, which they liked so much they've released it as a standalone
>   product. (
>
http://www.slotforum.com/forums/index.php?s=7e5384810bf0d8f2115151d974c7fb8b&sho\
wtopic=10876
> )
>
>   I'm currently working on a train simulator, which i'd love to use L3DT to
>   produce the terrain environment, but with a duration of less than 3 weeks,
> i
>   have no time to pursue it. Maybe in a version 2.
>
>   I've also had some success using L3DT output with Director, basic stuff at
>   first like loading the hieghtmap data. But more recently using Glex, an
> xtra
>   i've written with a collegue that intercepts the opengl code path of sw3d
>   allowing us to add new abilities, such as shaders, which I used with the
>   alpha maps for terrain splatting.
>
>   Sadly I ran out time to get it working at any level to show, but its still
>   on the backburner.
>
>
>   Noisecrime 2005
>  http://www.noisecrime.com
>
>
>
>  ________________________________
>  YAHOO! GROUPS LINKS
>
>
>  Visit your group "L3DT_users_group" on the web.
>
>   To unsubscribe from this group, send an email to:
>  L3DT_users_group-unsubscribe@yahoogroups.com
>
>   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>  ________________________________
>
>


--
Gravity.  It's not just a good idea, it's the law.

----- Original Message -----
From: "Aaron Torpy" <aaron_torpy@...>


> Hmmm....I'm not sure I'll be putting *everything* into
> the SDK. I really envisioned the SDK to be an easy
> tool with which other people can write file
> converters, and build their own map-handling
> applications.

I think i misunderstood what you meant, I thought you meant including
plugins in general, not plugin access or code into the sdk.


>  As for the
> terrain renderer plugin, I've been wanting to try my
> hand at this for a number of years now.

Well see you in another few years then ;)


> So long as you're using C++, there is hardly any
> setup. You only need to include 'zeolite.lib' in your
> linking list, add a few .cpp and .h files to your
> workspace, and then throw-in a couple of '#includes'
> and one 'extern' statement at the top any cpp files
> that use the SDK.

Sounds good, I've done a few dll plugins (heck Director is built around
them, but they are called xtras). I did start to work on one for Gile[s],
but as ever real-life got in the way. So hopefully i'm up to speed enough to
get it working.


> I wish you the best of luck, and congratulations on
> your excellent SW3D demos (I was just browsing your
> website). I was rather blown away by the
> shadow-mapping, water-reflection and texture-splatting
> demos. Really outstanding!

Thanks, those are getting pretty old now, in fact much of my more recent
work isn't even online.

One really nice project I did, that the L3DT sdk would have been really nice
for was Scalextric and their new Sportworld product. I wrote the complete 3d
editor, which they liked so much they've released it as a standalone
product. (
http://www.slotforum.com/forums/index.php?s=7e5384810bf0d8f2115151d974c7fb8b&sho\
wtopic=10876 )

I'm currently working on a train simulator, which i'd love to use L3DT to
produce the terrain environment, but with a duration of less than 3 weeks, i
have no time to pursue it. Maybe in a version 2.

I've also had some success using L3DT output with Director, basic stuff at
first like loading the hieghtmap data. But more recently using Glex, an xtra
i've written with a collegue that intercepts the opengl code path of sw3d
allowing us to add new abilities, such as shaders, which I used with the
alpha maps for terrain splatting.

Sadly I ran out time to get it working at any level to show, but its still
on the backburner.


Noisecrime 2005
http://www.noisecrime.com

Hello,

Okay, one more e-mail before I go to bed.

> Afterall what you mention is actual vertex geometry
> data, which too my knowledge L3DT doesn't have or
> use.

True enough. L3DT doesn't use vertex data, but it will
be supported indirectly in the SDK, since plugins can
define their own data structures.

> (of course if Aaron adds a 3D viewer or something
> then i can see this making more sense).

Ahah. You've got me there. I am planning on doing just
that, so geometry will probably come in a standard
(but non-core) plugin.

Cheers,
Aaron.

--- Noisecrime_PIPEX <atic73@...> wrote:

>
>
> ----- Original Message -----
> From: "M O" <rhoneranger2001@...>
>
> > I think for a plugin SDK you should be able to
> write
> > vertex formats.  For example, you take your map
> and
> > you are going to port it to OGL or DX9, and you
> want
> > your vertex to be in this way...
>
> Maybe I've misunderstood what you want, but surely
> the point of the sdk is
> to allow you to write exporters. Afterall what you
> mention is actual vertex
> geometry data, which too my knowledge L3DT doesn't
> have or use. Including it
> would somewhat pollute the nature of L3DT (bloating
> with stuff that is not
> part of the core responsability of the application)
> being that it only works
> on 2D images or hieghtmaps (of course if Aaron adds
> a 3D viewer or something
> then i can see this making more sense).
>
>
> Noisecrime 2005
> http://www.noisecrime.com
>
>

Hi Matt,

The file headers are there to identify the file type,
because file extensions are ambiguous. This is a
pretty standard ploy in both binary files (eg gif,
png, wav, to name a few) and text files (html,
etc...).

Anyway...one of the main ideas of the SDK is to
wrap-up the loaders for map files, mosaics, map
groups, etc, so that you don't have to worry about
headers and file structures. Rather than loading these
files using fseek etc, you can load them using the
plugin functions, and then retrieve the data you want.


Nevertheless, if you still want to chop-out file
headers, I will release the source-code for most of
the file I/O plugins, so you can modify them as
desired.

Cheers,
Aaron.

PS: Sorry if I sound a bit belligerent. The clock just
hit 2:00am, and I’m getting a little tired. G'nite.


--- M O <rhoneranger2001@...> wrote:

> Aaron,
>
> What I meant by no Header....  Is in the top of
> every
> other file you export now, you have a header
>
> l3dt
> version 1.x
> ....... etc etc
>
> In the SDK you should have the option to not do
> this!
> So if you want to go to the first chunk (tile),
> you
> can seekg(L3DTFILE,IOS::BEG); etc, or if you want to
> move a tile,
> seekg(L3DTFILE,5 * sizeof(Chunk));
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
>

Hi Andrea,

> For my personal use, i love to have only c++
> language, and a simple dll (not com object).
> I don't know if is usefull to have unicode in the
> sdk, i nevere used.

Excellent! So far this is 4/4 votes for C/C++, and 4/4
votes for non-unicode (I'm counting myself as the 4th
voter in each case, of course). Delightful!

Cheers,
Aaron.

--- Admin Kiraya <kiraya@...> wrote:

> Great Work.
> For my personal use, i love to have only c++
> language, and a simple dll (not com object).
> I don't know if is usefull to have unicode in the
> sdk, i nevere used.
>
>   ----- Original Message -----
>   From: Aaron Torpy
>   To: L3DT_users_group@yahoogroups.com
>   Sent: Monday, November 07, 2005 5:24 AM
>   Subject: [L3DT users' group] SDK progress report
>
>
>   Hi Everyone,
>
>   Here is the progress report for the SDK, as
> promised yesterday:
>
>   So far I've implemented a core DLL (called
> `Zeolite', as in the
>   mineral class, for no particular reason) that
> includes all of the map-
>   and memory-management code from L3DT. I've also
> written some nice
>   encapsulation classes (kind of like COM
> interfaces), which hides all
>   of the DLL-interfacing and greatly simplifies
> syntax.
>
>   This library also includes a management system for
> plug-in DLLs
>   (something sorely lacking from L3DT). Both
> applications and plugin
>   DLLs that use Zeolite can:
>
>   * create/delete/access data and maps stored in the
> Zeolite memory-manager.
>   * define new data types and map/image types.
>   * add new file formats & handle file load/save
> operations.
>   * define new functions that applications or other
> plugins can call
>   through the zeolite DLL (this is pretty neat).
>   * add custom event-handling functions (such as
> OnFileOpen, etc).
>
>   The plugin system is intended to separate all
> non-essential and
>   application-specific code from the core DLL, so
> that it can be as
>   fast, small and generalised as possible. Zeolite
> will include only a
>   few standard data types and map types, and no file
> I/O whatsoever -
>   everything else will be added through plugins.
> With the SDK I will
>   provide a set of standard plugins for handling all
> data types and file
>   formats currently supported by L3DT, along with
> the source code for
>   some or all of these plugins.
>
>   I'm writing a demo app in parallel with the SDK,
> which is a simple map
>   viewer and file converter that uses most of the
> SDK features and calls
>   a bunch of plugins. The source code for this app
> will also be included
>   in the SDK.
>
>   I should say that one of my main goals for this
> plugin is to make it
>   easier for other developers to write new file
> format loaders/savers.
>   The file I/O system in L3DT is not ideal, and it
> takes an inordinately
>   long time to add new formats or support for
> different map types. The
>   system in the SDK is much easier to use.
>
>   So, to summarise the progress:
>   * The core DLL is working, but a few things have
> yet to be implemented.
>   * I've written a plugin for load/save of HFF
> files, as well as some
>   example plugins to show how to add custom map
> types, data types, and
>   user-defined functions.
>   * The demo application can load/save map files
> (only HFF and mosaics
>   of HFF at the moment).
>
>   I'll release a beta once the core DLL is somewhat
> more complete.
>
>   Now, to for the questions to any potential users:
>
>   1) Is there any other functionality that you think
> should be included
>   in the core DLL?
>   2) What other plugins do you think should be
> included as standard?
>   3) What programming language(s) do you use? (I've
> written nice
>   wrappers for C/C++, but that's it so far).
>   4) Would you rather a COM object to a DLL?
> (Admittedly not much of a
>   difference, but probably worth asking)
>   5) What are peoples' thoughts on UNICODE strings?
>   (always/never/support both)
>
>   Cheers,
>   Aaron.
>
>
>
>
>
>
>
>   SPONSORED LINKS Backup software program
> Maintenance program software  Audit program software
>
>
>
>
------------------------------------------------------------------------------
>   YAHOO! GROUPS LINKS
>
>     a..  Visit your group "L3DT_users_group" on the
> web.
>
>     b..  To unsubscribe from this group, send an
> email to:
>      L3DT_users_group-unsubscribe@yahoogroups.com
>
>     c..  Your use of Yahoo! Groups is subject to the
> Yahoo! Terms of Service.
>
>
>
------------------------------------------------------------------------------
>
>
>
> [Non-text portions of this message have been
> removed]
>
>

Hi Simeon,

> > 2) What other plugins do you think should be
> > included as standard?
>
> Not sure what you're going to include, but i guess
> everything that makes L3DT what it is.

Hmmm....I'm not sure I'll be putting *everything* into
the SDK. I really envisioned the SDK to be an easy
tool with which other people can write file
converters, and build their own map-handling
applications. In general, I wasn't planning on
including many of the calculations, and perhaps only a
few re-usable bits of the user-interface will make it
in. I’m willing to hear arguments otherwise, of
course.

Oh yes, I forgot to mention in the previous mail that
other planned plugins include:
* Standard dialogs and controls (in dev.)
* Some sort of 3D terrain renderer.
* Client/server socket communication (TCP, UDP).
* Encryption/hashing (AES and SHA-256)

Not all of these will make it into the first
beta-release (probably only crypto and dialogs), but
these will be nice little side-projects for me to toy
with. I’ve written (and re-written, a zillion times)
the asynchronous encrypted network socket stuff for
work, so I think it would be nice to apply that
knowledge to L3DT. Perhaps a network-distributed
calculation manager (L3DT@home, anyone?). As for the
terrain renderer plugin, I’ve been wanting to try my
hand at this for a number of years now.

This is my wish-list, anyway.

> > 3) What programming language(s) do you use?
>
> C++ for me, using an old MSVC 6

Hah, me too. I'm using VC7.1 at work, but I still
prefer good-ol' VC6 for my homework. There's something
about that classic '98 interface that's so much nicer.


> > 4) Would you rather a COM object to a DLL?
> (Admittedly not much of a
> > difference, but probably worth asking)
>
> Not bothered, just as long as its not too hard to
> get set up.

So long as you're using C++, there is hardly any
setup. You only need to include 'zeolite.lib' in your
linking list, add a few .cpp and .h files to your
workspace, and then throw-in a couple of '#includes'
and one 'extern' statement at the top any cpp files
that use the SDK.

As to actually using the SDK, the encapsulation
classes make this all nice and object oriented. To
load a map, it is just:

CZeoMap Map; // declare a map
if(!Map.LoadNewMap(lpFileName, NULL, 0)) {
   AfxMessageBox("Error loading file");
   return;
}

Saving files is about the same, although you can play
around with the file format options as required.
Getting/setting map data is just a call to
Map.GetPixel(int x, int y, void* pPixelData) and
Map.SetPixel(int x, int y, void* pPixelData).
If you want to be hardcore, you can also get pointers
to the memory arrays of maps and mosaic tiles for
faster direct access.

To call a function defined in another plugin is also
pretty easy. Below is an example of calling a function
named 'File.ShowHeader.HFF' (nested names are
supported), which takes an argument of a string
(lpFileName, in this case):

CZeoFunc Func; // declare a function wrapper
if(Func.GetByName("File.ShowHeader.HFF")) {

   // now set the function argument 'FileNameStr'
   // to the value given in lpFileName
   Zeolite.str_SetValue(Func.ArgA("FileNameStr"),
                        lpFileName);

   Func.Execute(); // call the function
}

As you can see, there is a little bit of a coding
overhead in calling plugin-defined functions, but I
don't think it's too bad. Oh yes, to speed things up
you can store the function handles so you don't have
to keep calling Func.GetByName(string), and you can
also address function arguments by index, rather than
by name (eg. Func.ArgI(0) is equivalent to
Func.ArgA("FileNameStr"), but is faster).

> > 5) What are peoples' thoughts on UNICODE strings?
> > (always/never/support both)
>
> Never looked at them, but the subject always strikes
> fear into me for some reason ;)

Too true. I was blissfully ignorant of Unicode until a
couple of years after I started programming L3DT, by
which time the damage was done. While the MFC string
template handles all this stuff fairly neatly, I
suspect there are a few instances where I've casted
blindly to char*. I've cleaned-up most of the string
stuff in the SDK to be unicode-compliant, but I've yet
to really test this.

> I only wish I had more time at present to
investigate
> it, but with a rush client job on i imagine it will
> be a few weeks before i get a chance.

I wish you the best of luck, and congratulations on
your excellent SW3D demos (I was just browsing your
website). I was rather blown away by the
shadow-mapping, water-reflection and texture-splatting
demos. Really outstanding!

Best regards,
Aaron.


--- Noisecrime_PIPEX <atic73@...> wrote:

>
>
> ----- Original Message -----
> From: "Aaron Torpy" <aaron_torpy@...>
>
>
> > Here is the progress report for the SDK, as
> promised yesterday:
>
> Hey Aaron, this is great news and very exciting. I
> only wish I had more time
> at present to investigate it, but with a rush client
> job on i imagine it
> will be a few weeks before i get a chance.
>
> > So, to summarise the progress:
> > * The core DLL is working, but a few things have
> yet to be implemented.
> > * I've written a plugin for load/save of HFF
> files, as well as some
> > example plugins to show how to add custom map
> types, data types, and
> > user-defined functions.
> > * The demo application can load/save map files
> (only HFF and mosaics
> > of HFF at the moment).
>
> All in all it sounds pretty good and should vastly
> increase the usability of
> L3DT.
>
> > Now, to for the questions to any potential users:
>
> > 1) Is there any other functionality that you think
> should be included
> > in the core DLL?
>
> Well the essentails are input/export data and
> manipulate data which i
> believe you've got covered.
> I guess others may become apparent once poeple start
> using the SDK.
>
> > 2) What other plugins do you think should be
> included as standard?
>
> Not sure what you're going to include, but i guess
> everything that makes
> L3DT what it is.
>
>
> > 3) What programming language(s) do you use? (I've
> written nice
> > wrappers for C/C++, but that's it so far).
>
> C++ for me, using an old MSVC 6
>
>
> > 4) Would you rather a COM object to a DLL?
> (Admittedly not much of a
> > difference, but probably worth asking)
>
> Not bothered, just as long as its not too hard to
> get set up.
>
> > 5) What are peoples' thoughts on UNICODE strings?
> > (always/never/support both)
>
> Never looked at them, but the subject alwasy strikes
> fear into me for some
> reason ;)
>
> Thanks for your hard work on this, i'm sure it will
> pay off in the long run.
>
> Noisecrime 2005
> http://www.noisecrime.com
>
>

Aaron,

What I meant by no Header....  Is in the top of every
other file you export now, you have a header

l3dt
version 1.x
....... etc etc

In the SDK you should have the option to not do this!
So if you want to go to the first chunk (tile),   you
can seekg(L3DTFILE,IOS::BEG); etc, or if you want to
move a tile,
seekg(L3DTFILE,5 * sizeof(Chunk));




__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

Great Work.
For my personal use, i love to have only c++ language, and a simple dll (not com
object).
I don't know if is usefull to have unicode in the sdk, i nevere used.

   ----- Original Message -----
   From: Aaron Torpy
   To: L3DT_users_group@yahoogroups.com
   Sent: Monday, November 07, 2005 5:24 AM
   Subject: [L3DT users' group] SDK progress report


   Hi Everyone,

   Here is the progress report for the SDK, as promised yesterday:

   So far I've implemented a core DLL (called `Zeolite', as in the
   mineral class, for no particular reason) that includes all of the map-
   and memory-management code from L3DT. I've also written some nice
   encapsulation classes (kind of like COM interfaces), which hides all
   of the DLL-interfacing and greatly simplifies syntax.

   This library also includes a management system for plug-in DLLs
   (something sorely lacking from L3DT). Both applications and plugin
   DLLs that use Zeolite can:

   * create/delete/access data and maps stored in the Zeolite memory-manager.
   * define new data types and map/image types.
   * add new file formats & handle file load/save operations.
   * define new functions that applications or other plugins can call
   through the zeolite DLL (this is pretty neat).
   * add custom event-handling functions (such as OnFileOpen, etc).

   The plugin system is intended to separate all non-essential and
   application-specific code from the core DLL, so that it can be as
   fast, small and generalised as possible. Zeolite will include only a
   few standard data types and map types, and no file I/O whatsoever -
   everything else will be added through plugins. With the SDK I will
   provide a set of standard plugins for handling all data types and file
   formats currently supported by L3DT, along with the source code for
   some or all of these plugins.

   I'm writing a demo app in parallel with the SDK, which is a simple map
   viewer and file converter that uses most of the SDK features and calls
   a bunch of plugins. The source code for this app will also be included
   in the SDK.

   I should say that one of my main goals for this plugin is to make it
   easier for other developers to write new file format loaders/savers.
   The file I/O system in L3DT is not ideal, and it takes an inordinately
   long time to add new formats or support for different map types. The
   system in the SDK is much easier to use.

   So, to summarise the progress:
   * The core DLL is working, but a few things have yet to be implemented.
   * I've written a plugin for load/save of HFF files, as well as some
   example plugins to show how to add custom map types, data types, and
   user-defined functions.
   * The demo application can load/save map files (only HFF and mosaics
   of HFF at the moment).

   I'll release a beta once the core DLL is somewhat more complete.

   Now, to for the questions to any potential users:

   1) Is there any other functionality that you think should be included
   in the core DLL?
   2) What other plugins do you think should be included as standard?
   3) What programming language(s) do you use? (I've written nice
   wrappers for C/C++, but that's it so far).
   4) Would you rather a COM object to a DLL? (Admittedly not much of a
   difference, but probably worth asking)
   5) What are peoples' thoughts on UNICODE strings?
   (always/never/support both)

   Cheers,
   Aaron.







   SPONSORED LINKS Backup software program  Maintenance program software  Audit
program software


------------------------------------------------------------------------------
   YAHOO! GROUPS LINKS

     a..  Visit your group "L3DT_users_group" on the web.

     b..  To unsubscribe from this group, send an email to:
      L3DT_users_group-unsubscribe@yahoogroups.com

     c..  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


------------------------------------------------------------------------------



[Non-text portions of this message have been removed]

----- Original Message -----
From: "M O" <rhoneranger2001@...>

> I think for a plugin SDK you should be able to write
> vertex formats.  For example, you take your map and
> you are going to port it to OGL or DX9, and you want
> your vertex to be in this way...

Maybe I've misunderstood what you want, but surely the point of the sdk is
to allow you to write exporters. Afterall what you mention is actual vertex
geometry data, which too my knowledge L3DT doesn't have or use. Including it
would somewhat pollute the nature of L3DT (bloating with stuff that is not
part of the core responsability of the application) being that it only works
on 2D images or hieghtmaps (of course if Aaron adds a 3D viewer or something
then i can see this making more sense).


Noisecrime 2005
http://www.noisecrime.com

----- Original Message -----
From: "Aaron Torpy" <aaron_torpy@...>


> Here is the progress report for the SDK, as promised yesterday:

Hey Aaron, this is great news and very exciting. I only wish I had more time
at present to investigate it, but with a rush client job on i imagine it
will be a few weeks before i get a chance.

> So, to summarise the progress:
> * The core DLL is working, but a few things have yet to be implemented.
> * I've written a plugin for load/save of HFF files, as well as some
> example plugins to show how to add custom map types, data types, and
> user-defined functions.
> * The demo application can load/save map files (only HFF and mosaics
> of HFF at the moment).

All in all it sounds pretty good and should vastly increase the usability of
L3DT.

> Now, to for the questions to any potential users:

> 1) Is there any other functionality that you think should be included
> in the core DLL?

Well the essentails are input/export data and manipulate data which i
believe you've got covered.
I guess others may become apparent once poeple start using the SDK.

> 2) What other plugins do you think should be included as standard?

Not sure what you're going to include, but i guess everything that makes
L3DT what it is.


> 3) What programming language(s) do you use? (I've written nice
> wrappers for C/C++, but that's it so far).

C++ for me, using an old MSVC 6


> 4) Would you rather a COM object to a DLL? (Admittedly not much of a
> difference, but probably worth asking)

Not bothered, just as long as its not too hard to get set up.

> 5) What are peoples' thoughts on UNICODE strings?
> (always/never/support both)

Never looked at them, but the subject alwasy strikes fear into me for some
reason ;)

Thanks for your hard work on this, i'm sure it will pay off in the long run.

Noisecrime 2005
http://www.noisecrime.com

Hi Matt,

> I think for a plugin SDK you should be able to write
> vertex formats.

Certainly. You get full access to the data, so you can
do what you like with it.

> ALSO:  NO HEADER IN THE SDK EXPORTER!!!! :)

I'm not sure what you mean there. Can you explain?

> Now, as far as unicode, in order to be truly cross
> platform with this sdk, I would say support it
> eventually, but not necesarrily right now.

That’s reassuring. I'll add a Unicode version once
enough people are screaming for it.

> As far as languages, C/C++ should be okay, maybe
> just fine.

Also reassuring, since I only really know C/C++
anyway. I could possibly write some stuff for VB or
Delphi if required, but it would take 10 times longer
since they're not my 'native' language.

> P.S. Another opinion is to bring back your control
> points for splines, and have that as an export
> option too!.

Okay, I'll put that on the plugin wish-list.

Cheers,
Aaron.


--- M O <rhoneranger2001@...> wrote:

> Aaron,
>
> I think for a plugin SDK you should be able to write
> vertex formats.  For example, you take your map and
> you are going to port it to OGL or DX9, and you want
> your vertex to be in this way...
>
> ALSO:  NO HEADER IN THE SDK EXPORTER!!!! :)
>
> Vector3 for Postion
> Vector3 for Normal
> Vector2 for TexCoord
> Vector2 for TexCoord2 (alpha map for example)
>
> The user should be able to take this from your
> mosaic,
> and export out a mosaic chunk directly from L3DT.
>
> SO, when loading, you would then be capable of
> loading
> directly into a VertexBuffer using a memcpy.
>
> struct Vertex
> {
>    vector3 Pos;
>    vector3 Norm;
>    vector2 tex1;
>    vector2 tex2;
> };
>
> File f;
> f.open(L3DTFIle);
> f.seekg(where in the file);
> Vertex Lump(ChunkSize * ChunkSize);
>
f.read((char*)&Lump),ChunkSize*ChunkSize*Sizeof(Vertex));
> ////////////////////////////////////////////////////
>
> Now, as far as unicode, in order to be truly cross
> platform with this sdk, I would say support it
> eventually, but not necesarrily right now.
>
> As far as languages, C/C++ should be okay, maybe
> just
> fine.
>
> Great Work!
>
> -Matt
>
> P.S. Another opinion is to bring back your control
> points for splines, and have that as an export
> option
> too!.
> --- Aaron Torpy <aaron_torpy@...> wrote:
>
> > Hi Everyone,
> >
> > Here is the progress report for the SDK, as
> promised
> > yesterday:
> >
> > So far I've implemented a core DLL (called
> > `Zeolite', as in the
> > mineral class, for no particular reason) that
> > includes all of the map-
> > and memory-management code from L3DT. I've also
> > written some nice
> > encapsulation classes (kind of like COM
> interfaces),
> > which hides all
> > of the DLL-interfacing and greatly simplifies
> > syntax.
> >
> > This library also includes a management system for
> > plug-in DLLs
> > (something sorely lacking from L3DT). Both
> > applications and plugin
> > DLLs that use Zeolite can:
> >
> > * create/delete/access data and maps stored in the
> > Zeolite memory-manager.
> > * define new data types and map/image types.
> > * add new file formats & handle file load/save
> > operations.
> > * define new functions that applications or other
> > plugins can call
> > through the zeolite DLL (this is pretty neat).
> > * add custom event-handling functions (such as
> > OnFileOpen, etc).
> >
> > The plugin system is intended to separate all
> > non-essential and
> > application-specific code from the core DLL, so
> that
> > it can be as
> > fast, small and generalised as possible. Zeolite
> > will include only a
> > few standard data types and map types, and no file
> > I/O whatsoever -
> > everything else will be added through plugins.
> With
> > the SDK I will
> > provide a set of standard plugins for handling all
> > data types and file
> > formats currently supported by L3DT, along with
> the
> > source code for
> > some or all of these plugins.
> >
> > I'm writing a demo app in parallel with the SDK,
> > which is a simple map
> > viewer and file converter that uses most of the
> SDK
> > features and calls
> > a bunch of plugins. The source code for this app
> > will also be included
> > in the SDK.
> >
> > I should say that one of my main goals for this
> > plugin is to make it
> > easier for other developers to write new file
> format
> > loaders/savers.
> > The file I/O system in L3DT is not ideal, and it
> > takes an inordinately
> > long time to add new formats or support for
> > different map types. The
> > system in the SDK is much easier to use.
> >
> > So, to summarise the progress:
> > * The core DLL is working, but a few things have
> yet
> > to be implemented.
> > * I've written a plugin for load/save of HFF
> files,
> > as well as some
> > example plugins to show how to add custom map
> types,
> > data types, and
> > user-defined functions.
> > * The demo application can load/save map files
> (only
> > HFF and mosaics
> > of HFF at the moment).
> >
> > I'll release a beta once the core DLL is somewhat
> > more complete.
> >
> > Now, to for the questions to any potential users:
> >
> > 1) Is there any other functionality that you think
> > should be included
> > in the core DLL?
> > 2) What other plugins do you think should be
> > included as standard?
> > 3) What programming language(s) do you use? (I've
> > written nice
> > wrappers for C/C++, but that's it so far).
> > 4) Would you rather a COM object to a DLL?
> > (Admittedly not much of a
> > difference, but probably worth asking)
> > 5) What are peoples' thoughts on UNICODE strings?
> > (always/never/support both)
> >
> > Cheers,
> > Aaron.
> >
> >
> >
> >
> >
> >
>
>
>
>
> __________________________________
> Yahoo! FareChase: Search multiple travel sites in
> one click.
> http://farechase.yahoo.com
>

Aaron,

I think for a plugin SDK you should be able to write
vertex formats.  For example, you take your map and
you are going to port it to OGL or DX9, and you want
your vertex to be in this way...

ALSO:  NO HEADER IN THE SDK EXPORTER!!!! :)

Vector3 for Postion
Vector3 for Normal
Vector2 for TexCoord
Vector2 for TexCoord2 (alpha map for example)

The user should be able to take this from your mosaic,
and export out a mosaic chunk directly from L3DT.

SO, when loading, you would then be capable of loading
directly into a VertexBuffer using a memcpy.

struct Vertex
{
    vector3 Pos;
    vector3 Norm;
    vector2 tex1;
    vector2 tex2;
};

File f;
f.open(L3DTFIle);
f.seekg(where in the file);
Vertex Lump(ChunkSize * ChunkSize);
f.read((char*)&Lump),ChunkSize*ChunkSize*Sizeof(Vertex));
////////////////////////////////////////////////////

Now, as far as unicode, in order to be truly cross
platform with this sdk, I would say support it
eventually, but not necesarrily right now.

As far as languages, C/C++ should be okay, maybe just
fine.

Great Work!

-Matt

P.S. Another opinion is to bring back your control
points for splines, and have that as an export option
too!.
--- Aaron Torpy <aaron_torpy@...> wrote:

> Hi Everyone,
>
> Here is the progress report for the SDK, as promised
> yesterday:
>
> So far I've implemented a core DLL (called
> `Zeolite', as in the
> mineral class, for no particular reason) that
> includes all of the map-
> and memory-management code from L3DT. I've also
> written some nice
> encapsulation classes (kind of like COM interfaces),
> which hides all
> of the DLL-interfacing and greatly simplifies
> syntax.
>
> This library also includes a management system for
> plug-in DLLs
> (something sorely lacking from L3DT). Both
> applications and plugin
> DLLs that use Zeolite can:
>
> * create/delete/access data and maps stored in the
> Zeolite memory-manager.
> * define new data types and map/image types.
> * add new file formats & handle file load/save
> operations.
> * define new functions that applications or other
> plugins can call
> through the zeolite DLL (this is pretty neat).
> * add custom event-handling functions (such as
> OnFileOpen, etc).
>
> The plugin system is intended to separate all
> non-essential and
> application-specific code from the core DLL, so that
> it can be as
> fast, small and generalised as possible. Zeolite
> will include only a
> few standard data types and map types, and no file
> I/O whatsoever -
> everything else will be added through plugins. With
> the SDK I will
> provide a set of standard plugins for handling all
> data types and file
> formats currently supported by L3DT, along with the
> source code for
> some or all of these plugins.
>
> I'm writing a demo app in parallel with the SDK,
> which is a simple map
> viewer and file converter that uses most of the SDK
> features and calls
> a bunch of plugins. The source code for this app
> will also be included
> in the SDK.
>
> I should say that one of my main goals for this
> plugin is to make it
> easier for other developers to write new file format
> loaders/savers.
> The file I/O system in L3DT is not ideal, and it
> takes an inordinately
> long time to add new formats or support for
> different map types. The
> system in the SDK is much easier to use.
>
> So, to summarise the progress:
> * The core DLL is working, but a few things have yet
> to be implemented.
> * I've written a plugin for load/save of HFF files,
> as well as some
> example plugins to show how to add custom map types,
> data types, and
> user-defined functions.
> * The demo application can load/save map files (only
> HFF and mosaics
> of HFF at the moment).
>
> I'll release a beta once the core DLL is somewhat
> more complete.
>
> Now, to for the questions to any potential users:
>
> 1) Is there any other functionality that you think
> should be included
> in the core DLL?
> 2) What other plugins do you think should be
> included as standard?
> 3) What programming language(s) do you use? (I've
> written nice
> wrappers for C/C++, but that's it so far).
> 4) Would you rather a COM object to a DLL?
> (Admittedly not much of a
> difference, but probably worth asking)
> 5) What are peoples' thoughts on UNICODE strings?
> (always/never/support both)
>
> Cheers,
> Aaron.
>
>
>
>
>
>




__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com