3D Engine Update

This blog post only exists to prevent expired linking. My blog has moved to: http://pabloaizpiri.com/

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

So my pet project of writing a simple 3D engine basically was halted ever since my last "JDX Engine" post.... I've been busy; I got married, received a promotion, moved, and bought a house- so it's been crazy. However, I think a big part of it was also that I let it stagnate and never came back to it. I also know I'm reinventing the wheel writing these kinds of things, and even though it's mostly a project to learn how to deal with the challenges in the 3D arena, it can be a bit demotivating when it takes a long time to really have anything of substance to demo when you can just pick up something like Unity.

Having said that, I will always find 3D engines and their challenges intriguing. I'd love to eventually build a simple game with a 3D engine of my own design. I ended up deciding to try again now that I'm more settled and I wrote another 3D engine, mostly through the help of Frank Luna's "3D Game Programming with DirectX 11" book. In spirit, it's the successor to "JDX" in that it's in C# and uses Slim DX.

I realize there's a good chance this will be a lot like my last 3D engine project- I'll make some progress and then I'll get bogged down with something and it may not get worked on for months. Maybe I'll never even touch it again. However, I enjoy building this kind of stuff, and I'm posting my code on GitHub, so maybe it will serve to help someone get started on their journey. Also open to feedback on it.

A lot like last time, it's pretty simple. I don't have support for the 3D Giles format like the previous engine, but I can't even seem to find that application anymore so that's probably for the better. I would like to find a good light mapper and then write support to import whatever its native format is so I have something that can start looking like a game. I'm thinking BSP seems most common but I haven't decided yet.

Here's what I do have:

• DirectX 11 via SlimDX - most modern DirectX API.
• Support for up to (currently) 8 dynamic lights - spot, directional, or point.
• New framework of classes that should make using available objects much more simpler and easier.
• Although still not full, much better support for MQO files. 
• Previous attempt only loaded triangulated meshed, this loads quads as well so you don't have to do anything special to your mesh in Metasequoia.
• Support for mirroring on the X-axis.
• Loads all Metasequoia objects individually and can organize them by material type for faster rendering. (The engine doesn't take advantage of this yet)

Here's a few screenshot showcasing what I have so far.

Further support for MQO files:

Metasequoia's sample "violin" (with Z-axis removed)	AH-64 Apache model
1 dynamic spot light; resource model from book.	3 dynamic spot lights

I think the main things that I need to add support for next are:

• Sprites
• Multi-textures.
• Support to load some common level/map format that includes light maps
• Optimization in rendering - this one will take a lot of work and would constantly be on-going.
• Minimizing calls to set materials/textures
• Scene graphs
• Frustum Culling

ABCpdf for Reporting and Rendering Table Borders

This blog post only exists to prevent expired linking. My blog has moved to: http://pabloaizpiri.com/

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

ABCpdf Awesomeness and Reporting

I love using ABCpdf when working on a project that needs to generate PDF files. It is very powerful and flexible. One of the main reasons I love, have used, and convinced companies I work for to purchase ABCpdf is because it can render a PDF file from HTML- and not just as a big PDF image either.

Anway, the idea of HTML to PDF is extremely powerful- often times rather than use a reporting package that requires tons of work to modify a report to the exact custom request of a customer, I would much rather generate an HTML page and convert it to PDF or whatever reporting format is requried. (PDF seems to usually be the most popular) This is has become invaluable, as editing or creating new HTML pages that pull data is easy, straightforward, quick and powerful, and with the ability tocovert the output to PDF I can now send the PDFs as reports or have them available for download. I've frequently avoided nightmares when updating or adding to reports, and I've been able to modify reports very quickly using this model.


Rendering HTML Table Borders with ABCpdf

Recently I found a "bug" of sorts when rendering an HTML table border using ABCpdf. It's a bit of an odd bug. Essentially the borders become different thickness and really distract from the table. Since reports often include tables, having tables show up correclty and properly formatted is crucial- after all, this is one of the main reasons I like to generate reports in HTML and then convert to PDF: aesthetic flexibility.

A picture is worth a thousand words- here is a screenshot of the browser's rendering of a table border:

That's perfect. Just what I want. Now convert it to PDF:

Ouch... whatever happened to those table borders? It's odd- because if you zoom in on the PDF borders show up fine: 

At first I thought it might be due to not enough pixel density, and that maybe I just needed to increase the "browser width" and image resolution settings on ABCpdf so I would have a sharper image to sample from. Then I realized ABCpdf is going to try to parse the table, since it's not an image, so had to be a CSS issue. Obviously the borders were being created in some way that shows the right size at a certain zoom but is slightly off- enough to show when you use a fit-to-screen size.

Sure enough it was- and the fix was rather simple. I had a 'style="border 1px solid black"' on the table tag, and then the cells within the table also included inline styling data. For some reason ABCpdf is processing these borders that are defined twice- (first in the table as a whole and then in the cells as necessary)- as "overlapping". Removing the inline styling information from the table tag and leaving it on the cells corrected the issue:

Yes, yes, I shouldn't be using "inline" styles AND potentially this would not even have been a problem with a table-less div layout, but I was working with what I had and I wasn't about to rewrite the page if there was a reasonable quick fix. I did however, remove most of the inline styles and replace them with CSS classes... you do what you can. :)