Closed alekasm closed 4 years ago
What's the problem exactly with requiring the .inc file?
Drawing the Teapot seems niche to example 3d rendering/hello world projects. I think both the functions (GeometricPrimitive, Geometry) and data would be better suited in a tutorial instead.
Long Story (optional): For portability (and probably longetivity) I intend on including DirectXTK in my project sources. I only want to include sources from DirectXTK that I'll be using, so I just dropped the included tools, Keyboard, Mouse, XboxDDS, pdb files, project files, etc., saving more than 10MB. Dropping TeapotData.inc meant that I had to make a "custom modification", instead of just omitting like the others. An argument can be made that I'm already "modifying" the release.
Feel free to just say no, I'm just happy to be using DirectXTK so thanks for your efforts.
Ah, so the Utah Teapot is the "Hello, world" of 3D graphics. That's why it's included along with a bunch of standard 3D polyhedral shapes.
It's easy enough to add a #define
to exclude it I suppose...
#ifndef NO_UTAH_TEAPOT
// Include the teapot control point data.
...
#endif // NO_UTAH_TEAPOT
I'm curious though what is the problem with leaving small unused functionality like this in the lib? DirectXTK is implemented as a static lib, so whatever features you don't use will never be linked into your executable. Deleting this would save just a few KB of source enlistment size, but make no difference at all to your final binary.
FWIW, it's about 2k bytes of data when complied into a binary.
But if a program doesn't call CreateTeapot, that'll be dropped entirely by the linker, right?
shawnhar - Most of my projects I usually statically link since I only use vanilla VC++. I tried to clean up as much non-essential/non-core DirectXTK sources as possible saving me about 10MB. The linker should be dropping the function calls regardless so there is no PE concern.
There's really no problem. Geometry is made up of common shapes except for Teapot which seemed better suited in a separate Hello World example/tutorial - hence why I suggested just moving that out. If Geometry/GeometricPrimitive classes are intended for only example usage, then I suppose keeping Teapot and its functions there makes sense.
Really not a big deal, you can just keep things the way they are - I've been using DirectXTK for less than a week.
The way I think about this is that GeometricPrimitive provides stuff that might be useful to developers for a variety of purposes. Actual production rendering using this kind of simple shape is not very common, but they are useful for debug rendering (e.g. drawing bounding spheres for meshes as a debug overlay) and also for writing graphics samples and prototyping work.
The teapot has proven useful over the years for the latter, because it's an easily recognizable shape that has both varying curvature and a complex topology. That makes it a useful testbed for trying out new rendering techniques.
Fair enough, it seems like Geometry/GeometricPrimitive is intended mainly for debug rendering - the names gave me a different first impression. Thanks for your comments and for working on DirectXTK.
The teapot example should not be baked into Geometry, allowing us to remove TeapotData.inc. Preprocess based on that file existing or finding another implementation would be preferable.