Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
For the moment, I'm working at rebuilding my work area, so am in no rush. My clone CAD program uses Boolean operations quite a bit, but has a lot of mesh smoothing operations as well. The math for perspective drawing is often a nightmare. Once you have a coded routine that works, it's tough to want to go back and do it over, still, what I have now is the product of numerous do-overs. Mine was designed with the idea of working like ProE, which it does reasonably well, not unlike Aibre Design; a similar clone, but a little different algorithm. One day, I'll start dreaming up a way to put both of these into a single, yes, monolithic, program, save for necessary dll's and such. In a way I'm already starting such by building a program that's a math editor and parsing engine combined. What I am not up to speed on is Python scripting and such. That editor is really the main project in view, thus the need to rethink my work area (without losing my chalkboard wall behind me... ;)
I was able to export, then convert my own object files from the clone program (I actually call it EClone or just EC) into blender, then save them again to work with DAZ. I could export from DAZ, Blender or Sculptris to EC, but the problem results when attempting to work on a mesh. Also, the object simply WILL NOT disgorge dimension one, so that's a waste. I succeeded in drilling a hole in a mesh facet, but upon export, it was unreadable by the other programs without going back through the two other programs to convert it again.
So... pretty much Blender and DAZ have my attention. It will be quite some time and a few extra monitors to use just for instruction videos and reference before I'm ready to compare DAZ renderings to Blender's.
FWIW, how well versed are you guys in Python? Say, the skinny on what purpose it serves?
Python provides a linguistic framework for accessing and modifying the state of Blender. It allows you to use a "high level language" to make changes to your scene, or in fact to almost anything in Blender (eg making new geometry, modifying existing geometry, exporting geometry etc etc). The Blender UI is part-coded in python as well, and as a python-programmer you have the ability to create new panels, add buttons or new shortcuts, and do _almost_ anything you like to the interface.
Fortunately you don't need to know anything about python to use blender (although once you become proficient, you'll probably find yourself wanting to script common operations to your workflow etc).
Python is basically the programming elite for the graphics world, only beaten by C++ itself. It's too bad DS didn't choose Python for it's scripting environment. Maybe they'll change that for DS5? After all, Maya moved from MEL to Python.
This is what we were trying to say about booleans. Even *if* the program doesn't blow up when working with them, they are almost impossible to export cleanly, thus they are useful usually only when not leaving the program (ever) that they were originally made in.
There are many other reasons for not using booleans but I get too worn out explaining it, as many others do. They are so tempting to users before they hit all the walls... suffice it to say, people won't go on about them often not because they don't have reason but because they've worn themselves out explaining it... so they just fall back eventually on 'I told you so...'
Why would you want Python? The core of the scripting is the application functions that are exposed, and DS is already pretty good about that: having "DS Python" would not make Blender or Poser scripts usable.
Edited to add necessary "not".
Is there a "not" missing there Richard? ... just because the language is the same, would NOT make the representation of data the same (at the moment you cannot use Blender python scripts in Poser, nor can you use Poser python scripts in Blender - the application objects and scene objects etc are just too different). (Imho) adding a DS Python interface wrapping the Qt-based DAZ objects would be do-able, but would not in general magically make it script-compatible with anything else (unless you deliberately set up the API like that... but that would be an... interesting... challenge, when it came down to transmogrifying the shader structures etc).
Transmogrifying... :-D (Somewhere in that I imagine Calvin and Hobbs...)
In AutoCAD we use AutoLISP. LISt Programming language. In downloading Blender and DAZ tutorials, I've seen a good bit of each' capabilities. It's fascinating to see how far programming has come since the days when 640 x 480 res was state-of-the-art at 256 colors. I don't know how many of you have ever actually worked on a drawing board, laying out a circular projection of a 2 point perspective drawing, or perhaps a so-called "diametric" drawing, but, from the programming aspect of just "ye olde K&R" C language, or worse yet Q-Basic calling mouse routines you rolled on you own using Debug/a, but the difference between 1 point, say for a flight simulator, and 2 or 3 point, for renderings like we do now, is like day and night. AutoLisp would require a few pages of code to produce a simple structure like "minecraft"'s guy, let alone have him move.
Now all that's buried inside a graphics .dll somewhere in the software's bin or library folder. In C++, (or even in VB and Pascal) the bounding box becomes a class and an inherent set of routines that changes with the roll of a mouse wheel... which we didn't have in DOS days.
At least now I can sleep at nights knowing Python is just another Lisp language.
It looks more to me, as I take all this in, like parametric modeling, Blender, and likely DAZ as well, revolve around Constructive Solid Geometry (CSG) techniques. For instance, we make a plinth and upon it a vase. The parts are stacked up like the "Michelin Man," so we can pull a particular layer in the stack to whatever we want with or without affecting the rest of it. It seems, though, that a Boolean modifier would merely change the vertices of whatever layer(s) of the stack it was affecting and the geometry would keep marching on. My own EC does that, but it only uses triangles where needed. At least now I know that I'M not the stupid one... :-D
If Blender or DAZ, either one, are having problems incorporating Boolean operations, then it's an internal class that is being overwhelmed because, likely, a floating point quantum is wanting to be converted to an integer. My solution to that has always been to use floats as variables where geometry is concerned, even to the extent of screen position. The float can always be truncated with modulo routines, but 10.01 will always raise an exception error when trying to convert it directly to an integer variable. I'm sure it would put the Blender and DAZ programmers to a hunt for a needle in a hay stack, but the results might ultimately get rid of the "I told you so" admonishment.
Blender has had boolean operations for a number of iterations now (at least since 2.49 that I recall, possibly earlier), and vertices have always been stored as floating-point positions in 3D space. Support for n-gons (faces with >4 edges, not necessarily planar) has been added recently though, and the "problem" with earlier iterations was the computation required to define general surfaces of intersection (or union or addition) using just tris and quads.
Accurate description of complexities has its price... in computers we see it as memory total vs that total minus memory overhead. Once we go to virtual memory, it all slows down... a lot. Referring back to CSG, in the case of non-planar faces, although that seems like an oxymoron a bit, the spherical vertex only needs a minimum of right triangles to define it, depending upon the degree of asymmetry involved. Symmetry, on the other hand, only requires one. When describing more complex mixtures of both, the simplest way I've found is, similar to with NURBS, to have the routine calculate an osculinflexion (also osculinflection), not unlike calculating an eclipse as it enters or exits. Whether we clip the tangential excess or not, it still amounts to radius origins, not the joining terminations. Where triangulation is concerned, the shape is faceted, but the raytracer still needs those radii.
Hehe... I have to admit I had to google a little there <(^_^)... but I think I follow your discussion.</p>
And on the topic of non-planar n-gons - invariably happens once geometry escapes and makes it's way into the hands of the general populace v(^_^)v.
(theoretically, I agree it is a bit of a misnomer - a "non-planar face" wtf?! o.0 - perhaps the term "face" has been overloaded a bit too far -- the new Blender bmesh structure now tends to refer to them as "polygons"... verts, edges, 'polygons', that make up the object - built in support for non-manifold objects too - all and any of which can be booleaned together X)... because _someone_ will try to do it, even if it's not particularly clean X).
If you boned up on those math terms, then you understand how a NURBS works. One needs to keep in mind the definition of a spline; literally "back to the drawing board." In reality, I'm looking at what the computer must do to allow NURBS poly-lines, let alone faces. Sometimes it is a couple empty aspirin bottles, or more, to retrace one's steps through a developing piece of software if we end up with a log jam downstream in the coding process. If we are diligent, writing down each routine separately, we may be able to find the bug quicker, but when you have a team of 10 or 30 programmers, a fundamental error propagates quickly. I usually find it is easier to start over sometimes and never, never rush. That's a benefit of being a one man show. A lot more to juggle, but in the end no critical piece of work can take its ball and go home...
In a CAD design program, one class will provide the basis for a triangle in space, one for a curve, another for a line, but they all must be able to talk to one another. If two shared edges create a non-planar surface, there WILL be a fillet or round, in reality. In 4Dimensional space, there is no such thing as a straight line or edge, but intersecting curves (there's that inflection again) can produce a spherical vertex. These are the fundamentals that amalgamate into a manifold object.
It would seem that perhaps the "clean" issue targets the need for filler triangles that, for instance, smooth the inner edge or surface of hole drilled through the complex vertex structure of a tree or maybe an airfoil. Is it possible that Blender and DAZ "think" in terms of surfaces instead of solids till the effects of physics must be applied? Of course there are more than one way to measure and record the same object.
While I'm not following all of the math aspects of your points drc... (I'm lazy and don't like to think that hard if I don't have to,) what I can say, which I think you hinted at in your last post, is that different programs use different structures and algorithms traditionally to represent the various objects and components and how they interact with each other. This has to do with the way that particular tool uses it's mathematical structure to represent objects internally due to it's own framework of manipulation of the structures and optimizations. When one goes to export an object, that structure needs to collapse down into something of a generic structure. The generic structures they are collapsed down into (obj, dae, etc etc...) are not uniform in their representation in different applications. Also, there are things that are represented in the internal structure that don't collapse well into the generic structure, so tradeoffs are made. In the end, it means that things get jacked up the minute one passes from one application to another, and booleans are particularly susceptible to falling apart under this paradigm. All math aside, as the particular implementations vary, until the industry irons out more fully fledged and uniformly accepted structures for passing objects, these types of issues will continue to crop up. It is an ongoing process similar to what happens with html, css etc...
I was pondering this entire issue in lieu of counting sheep last night...
As you say, basically, each program handles the same problem a different way. It's been like that for years and with the onslaught of more available operating systems, it becomes worse for the programmer, even though most compilers have cross-platform capabilities.
It makes for good discussion, though. So far, in Blender and DAZ both, I like what I see. I'll probably get Hex for kicks, but Bryce doesn't support rigging and the work I've seen appeared to lack much contrast between the albedo of terrain objects, i.e. plants and trees. That may be the user's doing, but the rigging is a must have.
One thing that deters from any product, open or otherwise, is the sheer frustrations of trying to download, or even watch, YouTube video. If you aren't very watchful, you end up downloading an unwanted ad instead of the tut. Knock-offs aren't much fun either. To do YouTube, I had to upgrade to IE10 when I was happy with 8. Now the bugs in it make signing in somewhere, even here, a redundancy when I'm the only user or my machine. :(
As for the meshes, I gather the recommended success method will be to subdivide, then remove/add faces? Say, for example, instead of a Boolean subtraction, to drill a hole I'd be wiser to subdivide, then pull a node of vertices through the object's other side?
I find Firefox works better for me.
Been there. Did that. Flushed it.
I think I have enough to get by for a while. Eventually, I'll start polling Barnes & Noble. I don't think it's IE problemizing the downloads, but YouTube cramming ads at me like McDonalds with their French fries. I'd rather pay YouTube a few bucks each year for ad free use.