Semi-Functional

Ok.  After a long day in the trenches I have the OSX version almost back to running and with all of the targeted improvements in place.  There is a good bit of glue code that still needs to be put in place (for key presses and mouse movements and such), but the fundamentals seem to be working.

The basic idea behind what I did is this:

1. Move to a Document Type manager - using abstract factories, each document type (think Part, Assembly, Visualization, etc) registers themselves and passes a factory.  Then when anyone asks the Wildcat kernel (also a new class) for a document of a particular type it can then create it.
2. Move to a core OpenGL context - when the kernel starts it creates its own OpenGL context which can then be used to see what the capabilities of the graphics card are much more easily.  This core context is now shared with each document thus greatly reducing document creation time and graphics memory overhead.  Big improvements should come from this.
3. Building on 1 & 2 - once I moved to this new kernel arrangement I was able to clear a lot of cruft out and clean up the platform independent side of things.  This obviously has a direct impact on the platform specific code and that is what is going to take some clean up work.  But that is for tomorrow!

Hope some of this makes sense.  These are things I have wanted to do for a while and the nearly daily emails asking if such and such a graphics card is supported finally put me over the edge and I decided to just jump in and do it.

Check back in next week and hopefully things will be back up and running fully.

Cheers,

   Graham

I Think I Broke It

I decided to make some fundamental changes to the underlying way in which the Wildcat kernel interacts with OpenGL.  On the plus side it will make things much cleaner and clearer moving forward.  On the minus side: a) there is still much work to be done to get this working on any platform, and b) while it is in a running state on the OS X side, the Win32/WX side is quite horribly broken.

While I have not tried compiling the WX project, I can save you some time.  I am oh so certain that I broke many things all over the place.  I hope to wrap up the OS X work tomorrow and start working on the WX code just after that.  The downside is that I have a trip planned from Wednesday through Monday, so if I don't resurrect things by the time I leave it will be broken through at least the weekend.  Sorry!

I will try my best to post an update tomorrow.

G

Intersections and Testing

As you may have noticed, I am starting to check in some code for all of the outstanding geometric intersections.  There are nine that need to be tackled:

• Surface-Point
  
• Surface-Line
  
• Surface-Curve
  
• Surface-Surface
  
• Trimmed Surface-Point
  
• Trimmed Surface-Line
  
• Trimmed Surface-Curve
  
• Trimmed Surface-Surface
  
• Trimmed Surface-Trimmed Surface
  

Some of these will be more challenging, some less.  In order to try out these routines I am also adding code to the Topological Union operation.  The goal is still full Boolean capabilities, but baby steps first.

Also, I have been playing around with some unit testing frameworks.  I would really like to get to the point where there is a nice automated unit testing suite for Wildcat.  Moving forward it will be necessary to regression test etc.  After spending some time looking at all of the open source unit testing frameworks out there I decided to adopt googletest.

There are a million and one testing frameworks out there.  My criteria were: simplicity, cross-platform, C++ support, and open source.  Googletest has most of the features I want with seemingly little overhead.  I should start checking in the initial tests I have written in the next few days.  They will be appearing under the Testing directory (makes sense huh?).

Cheers,

   Graham

Still Here

It has been far too long since I posted any updates.  I apologize for this.  As some of you may know, my real job is as a graduate student.  I am pursuing a Ph.D. in computer science.  Obviously the end point for this process is writing and defending a dissertation.  One step before that is to propose the research you want to conduct.  

I am hoping to use much of the work already done in Wildcat as a large portion of my dissertation.  This would seem to benefit everyone.  I would get my degree and be able to move Wildcat forward at the same time.  My advisor is open to this idea, but I need to write up my proposal.  Writing this document is what is currently consuming me.  Sadly the proposal itself doesn't do much for Wildcat, it just talks about what I will eventually do.  I hope to wrap up the proposal in the next month or two, so please be patient.

Thanks to everyone who has tried Wildcat.   Your continued enthusiasm is great motivation.

Cheers,

   Graham

Boolean Operations

Today's note is going to be quick.  Just two things...

First, on Wednesday Dan pushed out a Windows binary.  This is something that a large number of people have been asking for.  Well, he posted the binary and announced it and we haven't heard a thing since.  Has anyone tried it?  Please give us some feedback and let us know if it is working for you.

Second, I am staring in earnest on the Boolean operations code.  It is very interesting, but don't let anyone ever tell you that boundary classification and boolean operations are trivial.  Wow!  I am diving deep into the literature, but wow!  This is going to be a fun adventure.

Here are a couple of the key references I am working through:

• "Set Membership Classification: A Unified Approach to Geometric Intersection Problems" by R.B. Tilove
• "Boolean Operations in Solid Modeling: Boundary Evaluation and Merging Algorithms" by A. Requicha and H. Voelcker
• "An Introduction to Solid Modeling" by M. Mantyla

There are a bunch more, but this is where I am starting.  You might start to see some code appear in the topology_* files, but I am focusing on Slice and Union for now.

Again, please let us know how the Windows version is working for you.

Cheers,

   Graham

wxWidgets Wildcat.exe

I have added a zip file for Windows. It has Wildcat.exe, various dlls, and some picture files for the toolbar buttons. I don't know how to make an installer, so read the text file that gives you some extra instructions.

Scripting Support

On the Wildcat support forum we recently got a request to add support for the Lua scripting langauge.  If you have used Wildcat you know that currently no scripting languages are supported.  This is more an issue of having higher priorities than a lack of desire.  I am focused on getting the core modeling kernel up and running and Dan is working hard on the wx port and his own work.

I must admit that I have little background in scripting languages and have never embedded an scripting engine into any of my projects.  I fully understand the value of this and look forward to adding support in Wildcat.

To me the two crucial questions are:

1. What scripting languages make sense to support?  There are so many possible languages out there that we can't possibly support them all.  Which ones do you all want?
2. How can we make supporting a large set of scripting languages as easy as possible within the kernel?  I want to make it simple and straightforward to add support for a new language if someone want it.

The Lua requester has asked if we have object model documentation of Wildcat.  The simple answer is "No."  But, I have created a Doxygen configuration file that will generate a lot of very nice documentation automatically.  You can find this file in the source tree at "truck\Documentation\Developer\Doxyfile".  You may have to slightly edit some of the paths to account for your directory structure, but with this you can easily get object models and nice code docs.

Please let me know what else you need in order to try to add scripting to Wildcat.  I am more than happy to add in a Cocoa "script" window etc.  I am we can convince Dan to do this on WX also.

Cheers,

   Graham

Slight Progress Update

Sorry for being quite lately.  I have been very busy with my real job, but we are still making progress with Wildcat.  The Windows build (using wxWidgets) looks great.  Dan has done a great job.  Thanks to him.

I have slowly been adding better support for serialization.  There are quite a few features that don't have full serialization support yet, so I have been adding that in.  My motivation for this is so that I can have a reference part to use for coding boolean operations.  It is much easier, and faster, to just have a file that is opened instead of re-creating the part each and every time. 

The next three weeks are going to be crazy busy with my job, so don't expect a lot of updates.  Check the SVN for progress.  Once we are through the middle of October thinks should be a bit better.  One thing we are still really looking for is someone willing to help coordinate the Linux port.  I think that Dan has done the heavy lifting getting the WX build running, so it should be pretty easy for someone with a linux background.  Let me know if you can help.

Cheers,

   Graham

tool bars

I have added tool bars to the wxWidgets version of Wildcat. They are defined by the existing text file "toolbar_manifest.xml".
They all start at the top left, at the moment. I have to drag them to place.
I need to store their position for next time and allow the user to turn them on and off from the menu. The tiff files are all defined upside down!

wxWildcat

Graham, thanks for adding me as an author to your blog.
I am pleased you think wxWidgets is a good way forward for Wildcat.
It should mean that all user interface work can be done in one place, making the work easier, giving you more time to do the geometry stuff. The wxWidgets project I added is now as good for me as the MFC one. Hopefully more people will be able to build it, now that it can be built with Visual Studio 2008 Express. I'll add a toolbar next. The picture of me is from 5 minutes ago.

wxWidgets on the Way

Two posts ago I mentioned that Dan was starting on the wxWidgets port of Wildcat.  He has been making good progress and has checked in the initial code.  He has also already documented the build instructions for this project, here.  You can find pretty much everything you need to know there.  We are just getting started with this, so please be patient as we add better support.  This should make is much easier to have both a nice binary distro for Windows and also a Linux version.  If you have any questions about this work please post a message to the forum.

Cheers,

   Graham

A Quick Diversion

As I mentioned in my last post, Dan Heeks has offered to help out on Wildcat.  He is working on the paths necessary to support non-GPU machines.  Having spent nearly 18 months being the only person checking things into the repository it is kind of strange (but very welcome) to see new code appear as Dan works.  We are making good progress as Dan is now able to at least get Wildcat running and open a new document.  I never realized how much I made use of Vertex Buffer Objects (VBOs) and rectangular textures - neither of which are supported on the GMA 3100 chipset found in his computer.  Mostly I am trying to stay out of Dan's way at the moment!

Here is a quick screenshot I took this morning just for some eye candy.  Please to enjoy.

On my system sketching and extrusions are working quite nicely.  I am sure that there are profiles out there that will take it down, but even moderately complex ones are working for me as of now.

As a quick aside, since I am working away on all of the geometric intersection routines I needed a good way to quickly generate solids to intersect.  I can use any one of the existing planes and create two solids that intersect pretty easily, but I wanted a bit more.  So I have started to work on a dialog box that will allow for creation of arbitrary planes.  This is something that will absolutely be needed down the road so I figured why not now.  I have also mocked up the dialog box for pads (extrusions).  Here that one is:

Cheers,

   Graham

Intersections and Contributors

Hello,

I am working away on more of the geometric intersection algorithms.  I seem to keep getting distracted by exciting optimizations and improvements in other things.  You will see more of that in the coming days.  This should be exciting work though.

But the great news that I want to pass along is that Wildcat now has its first contributor outside of myself.  I would like to welcome Dan Heeks to the team.  He has decided to help add support for integrated-GPU platforms (i.e. GL earlier than 1.5) and to begin adding GUI support via wxWidgets.  Both of these improvements are highly anticipated and I really welcome the support.

Dan is also working on a couple of projects of his own.  The most notable is one that I hope we can eventually integrate with Wildcat.  HeeksCNC is his open source CAM software.  He blogs about it here and code is available here.  Check it out!  And thanks for joining Dan.  Its good to have some help.

More soon.  Cheers,

   G

Trimmed Surfaces are Back and Lookin' Nice

I finished up the majority of the optimizations related to trimmed surface generation.  For those that are interested I was able to remove completely any need to tessellate the projected trim profiles.  I also eliminated a lot of memory reads and writes to/from the GPU.  This was done primarily through the use of a new method I added to both NurbsCurve and NurbsSurface.

This interface is a companion to GenerateClientBuffers and GenerateServerBuffers, it is called GenerateTextureBuffers.  Now you can choose to generate curves and surfaces directly into the most efficient format for how you are going to use them.  Since there are at least four different generation paths for both curves and surfaces, I am sure that there are some holes in places, but the primary paths seem to work well.

The impact on performance is nice.  It is a bit tough to gauge exactly (I need to add better timing ability), but I estimate that the overall trimmed surface generation time was reduced by 25-50%.  Wahoo!

Pictures are coming.  Oh yeah, so is STL support.  Hmm...lots to do.

Cheers,

   Graham

No More Polygon Triangulation

First, thanks for all the great feedback last week.  I really appreciate everyone's support.  I was asked what the Windows version of Wildcat is lacking.  The core modeling functionality is identical so Win32 isn't lacking anything.  Where it is lacking is in the platform specifics and GUI.  I just don't know the Windows platform APIs well enough to do it justice.  I know that I have talked about using a purely WebKit-based UI, but now I am not so sure about this approach.  What I really need is someone interested in getting the Windows platform better supported via either Win32/MFC or wxWidgets.  Either one would be fine with me.  Wx would be great because then the Linux port would be that much easier.  If ya have some free time and want to chip in, just let me know!

Ok, about the title for today's post.  If you refer back to a post I did a couple of months ago about my approach for trimmed NURBS surfaces, one of the key steps was triangulating the projected trim curves.  This step is the only step that is on the CPU and is not the easiest to implement (I was going to move to using Shewchuck's triangle.c code).  Anyways...

So I was pulling together biblio sources for a paper I am beginning to write, and one of my sources listed another source I wasn't familiar with.  I followed the rabbit a bit and it turns out that there is a method for rendering convex polygons from their ordered boundary points in linear time.  All using the stencil buffer.  No more triangulation needed!  And now the entire trimmed surface generation algorithm will be GPU-based!!!!!  Whoot!

I am in the middle of implementing this approach.  Nothing checked in yet, but it should be up and running by the end of the week.  I will keep you posted and try to upload some screenshots for eye-candy.  It won't look crazy different, but it will be running much faster and be on a nice and clean theoretical basis.

Cheers,

   Graham

Moving Forward

Hello,

Well I am back from vacation and ready to dig in.  I got a nice chance to relax and contemplate some of the upcoming work I want to accomplish.  I also got a chance to think about what I want to prioritize and what I really need help on.

First, my highest priorities are getting both STL output and all of the remaining geometric intersection routines working.  Neither of these is too terribly difficult, but intersection will just be quite time consuming with lots of little details that need to be taken care of.  STL will be great to have so that the RepRap team can possibly start to try out Wildcat.

Second, I continue to get many requests for more Windows features and a Linux port.  I really really really want to support these platforms.  It is very important to me that Wildcat be able to include as many users as possible, and the entire kernel is being written as very platform agnostic.  But, I simply do not have the time to support these platforms myself.  Sadly, I am a Mac guy, enjoy programming for OSX, and have little desire or need to learn more platforms.  So, what I hope is out there is someone willing to help me pickup the slack for these two platforms.  The work should be mostly UI related as the kernel will continue to be developed for all three platforms.

Lastly, my "real" job is as a Ph.D. student.  For my sanity and my future I need to make sure that this keeps moving forward which will require more of my attention for the next few years.  Wildcat has been my obsession for the past three years and will continue to see significant effort from me, but I need to dial it back a bit.  Don't worry, Wildcat will still be updated almost daily, but the blog and documentation effort will see a bit of a hit.

I hope that everyone understands.  And thank you to all of the people that have voiced their support for this project.  I am happy to go it alone, but knowing that others are out there makes this journey much more fun.

Cheers,

   Graham

AFK

On Friday I update a bunch of stuff.  Sadly, most of it is not anything to get excited about.  Primarily it was cleaning up a lot of geometry generation paths.  I was starting into the STL export work and saw the sad state of some of the older Nurbs generation code, that I wrote last summer, and decided the time would be well spent improving that since so much relies upon it.

Also, this week got a bit busy at my real job since I had to prepare for an upcoming vacation.  You won't see many updates for several days as I will be hiking in the mountains.  Sorry.  On the plus side, I did make sure that everything compiles and runs OK on Windows.  I might have introduced a bug that will crash you pretty quickly if you try to project a point onto a circle.  There just wasn't time left on Friday evening to track it down and try to fix it.  I will get there, I promise.

Cheers,

   Graham

Got Distracted

To all of those waiting for STL output, sorry, but I got distracted yesterday and today.  When I was going through the steps necessary for generating tessellated trim surface output I came up with a nice optimization that could apply to both NURBS curves and surfaces.  I won't bore you with the gritty details of the approach.  If you are really interested just drop a comment and I will reply.

In addition to being faster, this optimization uses less texture memory and requires a good deal less setup for generation that the current approach.  It did require modifying every generation shader, but the changes were pretty minor.

I have been reading "Performing Efficient NURBS Modeling Operations on the GPU" repeatedly in order to get prepared for surface-surface intersection.  One of the neat parts of their approach is that their GPU-based generation routines don't have to generate the entire curve or surface but can generate just a sub-region.  They use this ability to iterate through repeatedly (almost Newtonian like) to get within a certain accuracy.  Well, the optimization I put in place lays the groundwork for Wildcat being able to do the same sub-region generation too.  Just need to make a few more tweaks and API changes and we should be all done.

In addition I move to using PBOs to copy curve and surface generation data for server-side generation.  This should be a nice improvement.  I had avoided doing this before because I was running into some driver bugs that would hang the system when I tried to call glReadPixels.

Wow...lots done in the last two days, but little to do with STL.  Getting good STL output really is a priority, I promise.  Hopefully next week.

Cheers,

   Graham

STL taking shape

Just a quick note tonight about my progress with STL export.  I spent some of this afternoon mocking up the export and it went just as easily as I expected.  I nearly finished the whole thing, just need to implement Trimmed Surface tessellation, which I think I can knock out tomorrow.  So, hopefully by end of day tomorrow, we will have nicely working STL output.  As soon as I can I will post a sample output file on the download page.  If you want to try it out tonight, from the Part Designer screen just press 'x' and output.stl will be written to the same directory as the Wildcat root directory.  Obviously, we will need to eventually get a proper window to choose an output file name etc.

One question for those that know STL.  The top level object in the STL file appears to be "solid", with facets below that.  It is very easy to generate multiple separate solid bodies in Wildcat, how should I handle this?  Can you have more than one "solid" in a single STL file?  Should the user have to select a single body in Wildcat?  If anyone knows, please post a comment.

Cheers,

   Graham

Topology for Part Pad is Done!

Today I wrapped up a few little fixes to the topology generation for extrusions (PartPad).  See the SVN notes for a few little caveats about two possible issues that will need to be addressed later.  Now I can move on to the really exciting things.

Over the weekend I will start working on the STL methods I talked about in the last few posts.  I have no way of testing the correctness of my output though.  Does anyone out there have the ability to test STL files?  If so, I am more than happy to generate the STL file and post it for download.  Or, you can run Wildcat and do it yourself.  If you want me to do it, what shape would you like (remember only extrusions at this point)?

I have also begun more background reading on boolean operations (also known as boolean merging).  I think that I will start with trying to do planar sections of a part and then progress to Union.  Does anyone have a preference on the order in which I attack the operations?

There is still a lot of outstanding geometric intersection work that will have to be done along the way, but I don't think it will be too too difficult.  Most of it is for the two types of surfaces.  Curves and lines are pretty good at this point, though I do have to code the routines for generating NURBS curves from a series of points (point interpolation).  Piegl and Tiller (The NURBS Book) have a bunch of good algorithms for this.

Have a great weekend.

Cheers,

   Graham