Coder looking to help out

[Robert Leahey]

Greetings all,

I m a long-time LDraw consumer, and an even longer-time software developer (currently working in C#.NET), and was wondering about any possible software development tasks I might try to help out with.

i.e. are there any pressing software needs, utilities missing from the LDraw family, tools that users regularly request, etc? Something I might be able to code in my small amounts of free time?

I'm a hard-core C# (and Delphi) object-oriented developer, but also have a great deal of experience in front ends as a UX specialist and graphic designer (so I'm good at UI layouts and creating little icons and that).

So...
- Developers: if you can use me, just let me know.
- Users: if you have a desire for some app, utility, or editor that doesn't yet exist, drop me a suggestion, please.

For instance, my dream LDraw project would be to recreate the MLCAD UI for improved usability, but I gather that's not going to happen... ;-)

[Michael Heidemann]

Hi Robert,
thank you very much for your offer for coding. As I am coding in vb.net it should be easy to use code from c#.net also in my application. Therefore I like to ask for the possiblity to develop a dll for simple viewer purpose.
Currently I am using a dll that is a spin of from LDView. It has many advantages, but some disadvantages. Currently it is not available for 64bit and no picture (screenshot) can be made.

If you think that this could be task for you, please let me know, so we can discuss this item in more detail.

cu
Michael Heidemann [mikeheide]

[Travis Cobbs]

Note: if you know basic C++, you could enhance the existing LDView DLL to support screenshots (both in-memory and to-disk), as well as doing a 64-bit build. I don't think that's what Michael was asking for, but doing a full LDraw viewer from scratch doesn't seem to me to be an ideal task to perform in "small amounts of free time".

Getting a Windows computer configured to build LDView the first time takes some effort, but once it's set up, adding to the DLL should be fairly straightforward. I just haven't been spending hardly any time on LDView over the past few years.

[Robert Leahey]

Michael, I'd love to help you out if I am able. Let's talk details offline; I'm at robert at leahey dot com.

[Michael Heidemann]

Hi Robert, you got mail

[Robert Leahey]

Hi Michael, sorry for the delay! I go in for some serious neck surgery next week and I'm trying to get things ready for that...
I'll shoot you an email reply.

[Robert Leahey]

Hi Travis, so LDView is your code, yes?
I've got the latest LDView from SourceForge and have it open in Visual Studio 2012 (not compiling yet, as you might imagine). Might you be able to point me towards the viewer source?
I'm primarily a C# developer, but can read C++ for the most part.

Thanks a bunch,

[Travis Cobbs]

Yes, I'm the primary author of LDView.

The DLL viewer that Michael is using is in the LDVLib project. If you look at LDVLib.h, you will see that it is a pure C API to LDView viewer functionality. Michael uses this API from C# using DllImport (aka Platform Invoke). It's possible that once you get LDVLib compiled as 32-bit, that simply switching to the x64 platform would allow you to do a 64-bit build, but since I haven't provided him one yet already, it's very possible that the Linker Inputs will have to be fixed for the x64 platform settings.

Adding support for snapshots would involve adding one or three new functions: one to take a snapshot to a specified path, and another to take an in-memory snapshot (with an associated memory cleanup function). The LDSnapshotTaker class (in the LDLib project) has functionality to do both things, but creating the functions with a C API in LDVLib is required in order for that functionality to be available in the DLL.

LDSnapshotTaker:aveImage() is for file-based snapshots, and LDSnapshotTaker::grabImage() returns an array of bytes that contains the image data in raw RGB form. I'm not sure what the best thing would be to do with the raw image data. Probably load it up into an HBITMAP out parameter. Note that most likely you would then need a separate function that frees up the memory used by whatever data format you choose to return to .Net. I would suggest implementing the file-base snapshot first, because it would be quite easy to then test from .Net, using .Net itself to load the file after it's created. That's not efficient, but once it's working, switching to purely in-memory should be relatively straightforward on the .Net side, while doing the actual in-memory snapshot implementation on the LDVLib side probably won't be trivial.

Send me an email to the LDView email address, and I'll try to give you instructions on getting LDView to compile in the first place. Note that I've never tried to compile it in VS 2012, but I don't see any particular reason why it wouldn't work fine. IIRC, I've compiled using the free VC++ 2010.

[Michael Horvath]

One tool I'd like to see is an intelligent heightfield generator.

I.e. one that can combine heightfields like these:

http://s421.photobucket.com/user/SharkD2...n.png.html

with ones made entirely out of studs. (I think MLCAD can generate these.)

What I mean by intelligent is that it should use studs or simple triangles depending on the situation, for instance when the slope of the surface is very high or very low. Sort of like the nice sculpted baseplates.

http://www.brickset.com/parts/?part=4530674

Bonus points if you can think of an intuitive way to *edit* and *modify* the heightfields.



Mike