To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cadOpen lugnet.cad in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / 8760
8759  |  8761
Subject: 
Ldraw DLL - Was: Ldglite must be faster
Newsgroups: 
lugnet.cad
Date: 
Tue, 1 Oct 2002 15:37:13 GMT
Viewed: 
1017 times
  
In lugnet.cad, Steve Bliss writes:
In lugnet.cad, Anders Isaksson wrote:

"Steve Bliss" <partsref@yahoo.com> skrev i meddelandet
In lugnet.cad, Anders Isaksson wrote:

Another (Windows) wish: I would very much like to see a .dll (with some
standardized interface) implementing LDRAW rendering on a supplied dc - • then
it would be sooo easy to build all those little helper programs, adding
functionality around the basic rendering engine.

Yah, I second this.  I've wanted one of these for years.  Even better
(for me) would be an ActiveX custom control.  I *think* one DLL could
support both approaches.

Just fix a DLL and it can be embedded into an ActiveX for anyone who thinks
he really needs it... (An ActiveX control is just a DLL with a standardized
(slow) interface).

An ActiveX control would be very useful for "all those little helper
programs", where the programmer really doesn't want to worry about all
the standard Windows grunge.  Especially if the ActiveX control could
add value over a disconnected dll/dc rendering setup (such as adding a
"PartDrop" event to allow the programmer to respond to parts being
WM_COPYDATA'ed onto the control).  But basically, it's a different
mindset.

Getting a DLL going first would be good; an ActiveX could be developed
later, perhaps.

Getting a bit more specific, it seems like the most basic, and perhaps
only, call to a DLL would be to render some LDraw code.  Something like:
  RenderLDraw(hDC, sLDrawCode, sWorkDir)
Where:
  hDC is your average everyday device context (it's been awhile since I
     played with this stuff - you mentioned dc, I'm assuming device
     context is the best handle to pass off)
  sLDrawCode is string (of whatever flavor) containing a bit of LDraw
     command code
  sWorkDir is the working directory (used to search for files).

This interface reduces the number of parameters while retaining (or all)
of the rendering control (color, position, view angle, scale).  It also
gives the calling program the ability to easily render either a file
(pass "1 <color> <position> <viewpoint> <file>" as sLDrawCode) or code
that only exists in memory.

I'm not sure why, but this popped into my head last night.  I think
perhaps it may not be all that hard to do.  The basic ingredients are
already there in the winOffScreenStart() function of ldglite.  I'd just
have to convert it to use the hDC passed to it instead of creating
one with a DIB.  I just might attempt this as a learning experience
since I don't think I've ever created a DLL before.

So, what sort of "flavor" were you thinking about for the sLDrawCode
parameter?  Should this perhaps be two parameters?  A dat file line
string and a rendering options string the like what you'd get on the
ldglite command line?  Or could the command line options be tacked on
at the end of the ldraw line to make it one string.  That way you could
skip the options if you want the default projection, lighting, line
size and quality, etc.

Don



Message has 2 Replies:
  Re: Ldraw DLL - Was: Ldglite must be faster
 
"Don Heyse" <dheyse@hotmail.spam....away.com> skrev i meddelandet news:H3B7E1.BAs@lugnet.com... (...) On second thoughts, it might be better to pass the DIB as the rendering surface, but I don't know if this is easily done from VB. (...) If all the (...) (22 years ago, 1-Oct-02, to lugnet.cad)
  Re: Ldraw DLL - Was: Ldglite must be faster
 
(...) I haven't looked at WinHandles in awhile, I don't have a strong preference for which way we go. Of course, if we choose right, we'll get some drawing parameters 'for free' -- I'm thinking (trying to remember) of window size, user-defined (...) (22 years ago, 3-Oct-02, to lugnet.cad)

Message is in Reply To:
  Re: Ldglite must be faster
 
(...) An ActiveX control would be very useful for "all those little helper programs", where the programmer really doesn't want to worry about all the standard Windows grunge. Especially if the ActiveX control could add value over a disconnected (...) (22 years ago, 5-Sep-02, to lugnet.cad)

39 Messages in This Thread:















Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR