Adding to Cart…
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.You currently have no notifications.
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
I agree. But it's a computer. Its job is to do stuff like that for you. They could write a simple app that leads you thru the process and categorizes the stuff the way YOU want and what makes sense for you, rather than some PA's names. You shouldn't have to do it manually, it should help you by doing the grunt work for you.
It should say "Um, this content is under a folder named 'Notilize', are you sure you dont' want me to put that into a more reasonable location?"
Now that would be cool... if it would be fully customizable:-) My categorizations are logical to me, but I wouldn't force them on anyone else.
Please fix the problem that started with the new release where the viewport controls spin around and have become highly sensitive especially in larger scenes. It makes positioning complex scenes quite impossible.
Is there actually a DAZ Studio 5 Alpha in the works?
No one knows beside Daz, and there's little chance they will tell us.
Well thanks. I don't think I've seen this mentioned before then after the dForce dynamic physics system is complete I'd like to see an updated physics-based animation system 1st, although that is more 4.x terrirtory & integrate a game engine to publish with 2nd, although the 2nd is probably way to out of scope even with an updated physics-based animation system.
I think this, to some extent, already exists in dForce as currently implemented.
Define "Physics based animation system"
Rigid body bullet Dynamics(Collaping buildings type simulations)
Soft body (Like poser has for the "jiggley bits "of the figure)
I dont see much interest in such features in the majority of the user base
here at least as they dont render animated scenes with moving actors
and that tiny minority who does is already using external solutions for these effects.
Even with the new Dforce it is apparent to my observations,
that it is largely a tool of the one framer majority
and frankly does not appear to hold up for locomotion walks of any length.
and forget about something like a balet dancer or karate fight animation
with loose draped dforce clothing
someone please show me a Dforce 5-10 second walk like this
Ask merchants like "PAthephilosopher" (spelling??)
who has released several amazing pre-animated products,
only to have the very first question to be "can this be used for stills??"
And now I see an up coming product that appears to use Dforce for transmapped hair
looks decent ...for still images .
During animation it will look quite rubbish
as those baked in transmaps will make the moving hair look as though it was
cut to length by beating it between two rocks.
but again it is not for animation it is for single images.
This is why I like Virtual World Dynamics (VWD) in DAZ Studio so much. Even with multiple layers of clothing it drapes super nice even in animation (works in Poser and DAZ Studio):
https://www.youtube.com/watch?v=HQJQ5BWthfo
I hear that my custom install got trashed a while back and I haven't had the time to redo it
I get really tired of looking for an enviroment only to find it in props or vice versa and shaders are even worse as are poses they're scattered everywhere
Exactly.
I put props that are 'places' in with Environments, etc.
I have some of the ThePhilospher's products on my wish list but my hardware is lacking to render any of them in an animation.
There are bits and pieces in DS but their needs to be a library of working dForce clothing and hair and interest will increase. I mean hair and clothing have to be designed from the ground up to work with dForce. Things like have DAZ George at that size jiggle when they walk would be nice too. They can re-edit old products but practically speaking it will be more efficient and cheaper to make new products that are clean & compliant.
Part of the reason people don't bother much with animations are are the hoops one has to jump through to make an animation with these specialized, and one has to admit, often broken and/or frustrating workflow pipelines. Even when eventhing is available in one place animating is tedious and difficult at best - it can be made easier but one imagines to be original with it will never be easy. When I say physics, I mean physics. Human scientists have researched and written down sets of physics laws, incomplete as they may be, no need to invent a new universe. And there are already multiple implementations of subsets of those laws in various software products and libraries so no need to reinvent the wheel there either.
Give the customers an animation solution without the frustrating pipelines and more will take up animation. If not, the pipelines are being massively improved to animation and game solutions like Unity, UE4, ... so it's not a big deal breaker. There still need to be speed and memory improvements though for any scene of even modest complexity.
...indeed. If built your own custom layout, you need more control over what goes where. This is why I won't use Connect. I also don't bother with Smart Content as it takes up too much screen "real estate" and I know where things are.
An update to the standalone Mimic Pro for Daz would be great.
A built-in hand and face camera ( like in Poser)
A way to return easily to recently used items in smart content. So many times, I want to change makeup on a character or a texture on clothing and having to wade through all products to get back to it and search doesn't always work and sometimes I forget the name of the character if it is just listed as Genesis.
All of smart content separated by generation. If you use autofit sometimes you don't know the generation of the clothes you're using if not in the product title.
Smart content fixed so everything actually goes where it belongs, not with a bunch of lost and found items,
A way to add your own altered content (or original content) to smart content. If there's a way to do that already then a tutorial on how to do it. I keep thinking there must be a way, but can't find it. A way to edit smart content in general with key words. Again, if this already exists, a tutorial on how to do it.
Having textures for a product in the same folder as the actual product in smart content.
A PRINTED OR PDF MANUAL WITH SCREENSHOTS.
A Mimic Pro plug in, usable on all characters.
Smart content updated for better kit bashing. Search for shoes brings up ALL shoes and the ability to see what generation it was created for. Search for jewelry brings up all jewelry, etc...
A comic outline style render function like Poser has, without the need to switch out all the materials. I upgraded to Poser Dev edition when it came out and the comic function on the newer version is the only new thing I wish I had. Not worth upgrading just for that, and I've barely used Poser in the past year or so because of it's lack of compatability with Daz's newer figures.
Nice idea - I already since quite a while thought that artist name (as propably DO-tag and generation) should best go into the filenames / displayed names instead of being used as folder names.
That would allow searching through one's library a lot faster, and especially for dials (ERC) it would be good to have that info displayed, too, and my best guess so far was to put it into the name of the dial... Could do so manually with some of the tools I got so far, but would likely take *very* long, so I didn't yet.
Seconded.
A more Iray freindly viewport, like for instance Substance Painter has, with real life animation possibilities like Blender's Eevee, has.
Greets, Ed.
P.S. and a comprehensive DAZ to Blender bridge like GOZ......but that may be hampered by the Blender site.....
The next version is either 4.11 or 5.0, depends how much of an upgrade to the existing it is.
Yeah, I haven't played with Eevee yet, but it *seems* like it will give real time feedback in the viewport, even with some very complex textures. And that's one annoyance I have with Studio. Even with two high-powered GPU's, there can be a delay in some scenes when moving around the viewport, or moving objects in the scene. I realize it's a tough thing to do to make it instant response, but if we could have an Eevee-type viewport it would be amazing. Although I tend to be skeptical of new technologies, and you rarely (never) get something for nothing, so I'm wondering how much work it takes to configure your scene to make Eevee work like that.
And the content thing just has to be fixed. I recently had some sort of glitch that messed up my content completely, and I still have no clue what I did. And to fix it I'll have to re-do all the work I did (many, many hours) to sort stuff between the Content Library and Smart Content. Big mess.
Oh, and in Iray viewport, when I click on an object to move it, often suddenly the view will go wonky and I'm all twisted up. And then I have to figure how to re-orient myself. Frustrating.
So yeah, if they could just stop and focus on improving the existing product I'd be much happier. I'm sure a lot of others would too. But I think that with a lot of software, people get used to the hassle and it starts to seem like it's no longer a hassle. Y'know, like ZBrush.
I would really love a “collision detector”option for Daz. So I could see if a finger is colliding though a shirt a foot in the floor or an arm out of whack. You’d have to be able to disregard clothing but I would find that useful.
Yes, that would be very nice! Just set a character, clothing, jewerly, hair, things they were holding into different layers and then run dForce on them to force them out of their erroneous through-cut intersections with other layers. Then we could do dForce simulations without explosions! It must be much more difficult mathematically as if seems that's what dForce with do 1st thing on it's list as a precondition to being able in creating a successful dynamic simulation.
My understanding is that the current Iray Viewport is actually trying to render the entire scene in full Iray rather than simply giving you the ability to view Iray materials in an OpenGL compatible viewport (which is what Iray Real-time actually does). This is why you get the pausing when moving around, and why I generally turn it off and work in the normal viewport with headlamp on.
Collision algorithums in physics based animation are based on a
(mostly)binary decison.
Hello..I have been informed you are a collision object for my dynamic cloth??
(informed by a primative global state imposed on every scene object by the simulation algorithum)
(or informed by user defined assignments to specific scene elements via object tags, checkmarks applied
to a scene item list as in Optitex and other systems.).
In this binary system those assigments keep the two parties from intersecting when they try to occupy
the same 3D space when they meet during movement
based on their assigned state as long as they are not already intersecting
when the math starts.
Daz has hedged this binary choice by assigning the dynamic
parts of the clothing via a weightmap.
There is nothing particularly clever about using a weight for this purpose
Poser/C4D Lightwave, MODO use weightmaps in this exact manner,
for things ranging from jiggly bodyparts to clone distribution& hair growth.
to expect Dforce or any other physics based to calmly decide that you really did not mean
to have those prerequiset(sp?) binary states in conflict and magically "un intersect" geometry
and then calculate an explosion free simulation ,is not logical .
It is like expecting the moon to detect my human presence and
instantly create an atmosphere before I suffocate.
Clothing designers will have to Avoid those intersection in the
Modeling process or the Explosions will continue.
I think it's a bit more complicated from that. Speaking from a programming perspective, you're working with time steps. And in a cloth sim the mesh (vertices) change position with each time step. So depending on the length of the time step and the motion of the mesh, you could suddenly find yourself with the mesh inside the collision object without knowing it. And I imagine trying to recognize and recover from that is probably real difficult. And I assume that's one reason why cloth sims suddenly explode.
I think it's not a miracle of science that a dynamic clothing simulation can figure out that a seperate model labeled as a sweater should not intersect through a human's body volume when it is parented to that human when labeled a human or intersect through a watch, necklace, blouse if they are labeled as such and accounted for in the algorithm(s). It has to be programmed to be so. Science and tehnology doesn't stand still no reason to think clothing fitting algorithms for 3D models should too just because they are what some are familiar with. The dynamics algorithm could be programmed to exclude any of the sweater's volume in the internal volume of the human model and likewise for the human model being excluded to be internal to any volume in the sweater interior. And then the sweater can be fit by fitting the arm sleeves around the arms, torso, and neck using the volumes and locations of those portions of those models using the bones and the weight maps. Maybe the HW ain't up to doing the mathematics yet or such a system needs to be intergrated into a modern fitting system to succeed autofit although I think autofit maybe does a simplified version of such a clothing fitting, however I don't know as I've never read one iota about it, just observed what it does in DS.
No it is not a miracle of science you have described exactly
how it works when it has been "accounted for" in advance
that is how basic programming Algorithihums function,
they set conditions and the programs executes based on those conditons.
Even science cant violate its own rules.
object "A" must NEVER intersect with object "B"
even if pulled or pushed by global forces such as gravity & Wind.
This is the "rule" that enables software to simulate how matter collides/repels
in a computer program.
Again all of the above is based on pre determined rules
before they can excute thier intructions properly.
I am a genesis clothing content developer.
there are RULES that I must follow for My custom clothing to function properly
under the projection mapped based auto fit algorithum of Daz studio.
(Model for the base ,shape dont have clothing geometry intersecting my base shape etc)
And for figure morphs maintain matching vertex count.
with physics software these rules are determined by the coders based on the limitations
of the formats being used.
its not real just a simulation for what happens in the physical world.
The real world is even less forgiving.
why were there no rubber space shuttle rocket booster "O-rings" capable of knowing that
the air temp was too low to maintian there structrural shape??
because the molecular structure of that type of rubber is not capable of
on the fly pattern recognition and adjusting to compensate.
It is not about not always about not having enough hardware processing power.
Brute force is not substitute for good programing proper use of the Software.
double deleted
Indeed that sudden intersection is what the one framers call "pokethrough"
as there are no time steps the software can recover as it is not having to face
continuous recalculations on the fly for a still non moving model
Explosions are caused by either Poor programming such as not having any options
to set collision offsets( come this X value close but NEVER actually touch!!)
Note how the prevailing Dforce advice is to turn off self collision
Or setting a rule and violating it even before the CPU math starts.
typically well designed animation based physics simulation will toss a courtesy
notification that "there are objects intersecting in the scene ..simulation may explode"
this is what the old python based poser physic plugin would do.
and I can tell you that intersecting geometry FROM THE OUTSET OF THE SIM will assure an "explosion"
so much so that I easily created virtual "Bombs" with the old poser physics plugin
by intentionally using multi-part models with intersecting peices.
sample:
You completely ignored that I said that algorithms can be improved, designed and capable of calculating volume and location of these volumes on the models in order to fit them and drape them and be improved from what they can do now. And faster hardware can help but I never suggested that faster HW was the sole need for an effective solution.
Will there be some clothing models and other models so broken as to break those algorithms. Yes. That's not a reason though the current situation can't be improved and enable the use of more 'boundary case models'.