Here's an even larger pic mshowing a V4 and a Genesis, for the sake of close-quarter comparison:

 

http://i48.tinypic.com/33cc9b8.jpg

 

take a look at the ears, the eyelids and eyelashes, and the lips for the most significant facial differences.

 

Cheers,

 

Cliff

Quote - I have your tutorial but haven't managed to put it into practise yet. Has SR3 altered the workflow significantly if I follow the tutorial? Anything specific I need to beware of?

 

Not really - towards the end of the workflow there's a few scripts I wrote to make the joint origin on clothing match the joint origin of the Genesis figure, as those joints can (do!) move between different "characters". That wasn't working before SR3 (which is why I wrote the scripts to do it) but now there's an option in the Properties of the Body of the conformers to tell Poser to do that work. IMO it seems to do a slightly better job than my scripts did for still images, but for animations it blows my scripts out of the water - as my scripts could not aniamte the joint centres at all.

 

I am toying with the idea of adding a new script to set this property on all conformers for a selected Genesis figure, but haven't gotten around to playing with that yet. hopefully the DAZ Studio .CR2 exporter will be updated to automatically include that property "soo..." anyway ;)

 

Cheers,

Cliff

This image should show the difference in polygon density - and should even highlight how most of the density on v4 doesn't really add much to the character. I think that if Genesis had just a little more definition in selected areas it would be much harder to tell the two figures apart.

 

Cheers,

 

Cliff

> Quote - 1. Someone said Genesis is lower poly and doesn't render up close as well as V4.  Is that true

It's quite true - Genesis IS a lowER resolution mesh. Here's some stats for you:

Victoria 4

vertices = 68498

facets = 66830

materials = 29

Genesis

vertices = 19296

facets = 18872

materials = 26

This DOES result in lower quality renders close-up. this can only be slightly mitigated by turning mesh smoothing on, and even tweaking the mesh can't completely hide the fact that it is lower resolution (the ears being a particular problem). I'll attach a comparison render of V4 and Genesis both wearing V4's default texture.

 

Quote - 2. I use Queue Manager constantly for games; can't live without it, I usually have 100s of frames being rendered in the background.  Does DS have a render queue?

 

The Queue manager is brilliant, and network rendering using Poser is vital to me. DAZ Studio doesn't have a render queue as far as I've been able to find. Such a feature has been requested repeatedly.

 

I hope this helps,

 

Cheers,

 

Cliff

It's currently running at less than 20 seconds, but I've got to work on it a bit more. Not sure I can be bothered to make it a "for sale" product as the low number of sales could be embarrasing, so it might end up being a freebie**. We'll see. Either way it has to be "good enough" by my own eyes to let others use, and therein lies the rub with releasing it as a product - although it's taken me a bunch of work, that's more because I'm not an experienced Pythin progrmmer than because the problem is complex. I expect an initial release to be followed by "I want it to work this way" or "I want it to do that" type responses - quite valid ones - so I expect a 1.1 and maybe a 1.2 release in "short order"*.

Cheers,

Cliff

*"Short order" depending on my other commitments - which are slowing down this project somewhat, so far. I keep having to do WORK for a living! :(

 

EDIT to attach image - comments welcome(ish). I'm using ".tvs" for "Texture Vertex Set" as technically that's what these load and save, so it doesn't save, load, or change seams.

 

**Don't assume that's a promise. It might embarrass me to release something that doesn't sell, but I use money to buy bread n stuff. a little humiliation can sometimes be stomached for the greater good.

Well, that was harder than it should have been! #1 accomplished, though I don't have a thumb design yet. #2 should be easier following #1, but #3 I'll have to think hard about.

 

Cheers,

 

Cliff

Hi - Sorry for the delay, I've had a quick holiday and even though I'm back now my head's not totally focussed yet.

OK - so what are we looking for?

 

1. Library thumb/icon to activate "Save" capability, to which you use a file browser window to specify a file patha nd name. Should be easy.

2. Library thumb to activate "Load" capability, where you'd have to browse to select the relevant uv set.

 

Would that be acceptable? Or would we need to try and find...

 

3. a way to generate a library thumb for each UV set that we might want to load?

 

I think I'll start working on #1 now, maybe even #2 if that goes well.

 

Cheers,

 

Cliff

SR3 is available! And well worth getting IMHO :)

 

WimvdB:

See http://poser.smithmicro.com/updates.html

This includes a fix which eliminates the need for some of Cliff's cloth fitting scripts when using genesis in Poser

It absolutely does a better job than at least 4 of my scripts, IMHO. Get SR3 - now :)

Cheers,

Cliff

I definiately prefer toons to realisitc generally, although I don't tend to do cel shaded type renders. Two of my favourites have been the variations on Kim Goosen's "Girl" and 3D Universe's "Toon Generations" which I actually bought specifically because they were almost exactly what I'd have had to make myself for a client, so I was quite happy that what I specifically wanted was (more or less) pre-made for me!

Toons can change their flavour quite a lot using skins and lighting - here's a December 2009 render of a version of "The Girl". So yeah, I'm always interested in toons - especially if I can see a particular use for them.

Good strong characters (like the guy in your avatar, who DOES have a hint of Delgado about him) are good - but I'm a little cautious about being TOO strong. If the character is too specific it seems to me easy for it to fail to appeal. Take: http://www.daz3d.com/shop/toon/toonimal-penguin/ as an example - for a while a bunch of toons coming out through DAZ had this "one big eye one little eye" built in to the base mesh, making it hard to do a scene using a bunch of the same figure (a flock of those penguins would look most off, for example). I'd rather the base mesh was symmetrical and odd characteristics like that were possibly thanks to rigging and/or morphs.

 

Cheers,

Cliff

Well, it looks like the PoserPython calls to change the UV values aren't where the speed issue lies - looks like it's simply the speed of Python iterating through tens of thousands of vertices :(

After optimising the speed a little, I was getting over 12 seconds for a Genesis UV swap - optimising the UV methods didn't seem to speed it up any more than that so I commented out the UV setting methods, and that made less than 2 seconds improvement on my machine - so still around 11 seconds without actually making the changes. As a result, I can't see any way to get the time down to 10 seconds WITH making the changes using Python. Sure, it can be done - but at that speed and with the seam limitations I don't think it's worth putting more effort into at this time. It'd be far better coded into Poser as native code than as a slow, interpreted script.

Cheers :(

Cliff

I'm pretty sure I can speed up loading a fair bit - not sure how I'd speed up saving at this point but I have an idea. Just need to find the time to have a bit more of a play with it.

 

Cheers,

 

Cliff

Nope :) the official setting is "High Resolution" - one step up from "Base".

When exporting Genesis the mesh level isn't set to "Base" though - it's set to "High Resolution". One step up, I thought, from the base mesh.

I can't how that'd be an improvement on just replacing the figure. Which we can already do right in Poser. I mean, if it's going to need a different .obj file then the existing way is already faster than anything I could script up in Python.

There may be SOME simple optimisations that I haven't done yet in tinkering around with old half-forgotten code, but beyond that it'd have to be newer cleverer optimisations that will make my brain hurt to attempt - or be in native code as part of Poser (in which case that's when I'd be more tempted to look at expanding the capability to being able to have different uv seams/uv counts).

Cheers,

Cliff

I haven't actually, for various reasons - and file reading and writing isn't a bottleneck, it's the speed of PoserPython methods to access the geometry which are the big bottleneck. Take those out and the script runs at lightning speed - but doesn't actually DO very much.

I'm not especially interested in the DSON file format at present, and using my own file format has the benefit that I control whether it gets outdated or not. Plus, of course, the file format structure is directly related to how the data is accessible within Poser - which from what Rob has said would mean I'd probably have a pretty nasty job having to try and work out how to extract the UV data from one of DAZ's DSON files usefully for my script.

This is a distinctly different project to the tut that tries to make Genesis as useable in Poser as possible - this is more for Poser native figures.

Meanwhile - $5? $5 isn't much, that could maybe work. That or free (depending on how much more work needs to be put in) sound reasonable.

Cheers,

Cliff

Edit for PS - and I've a sneaky suspicion that the DSON files wouldn't be any used for Poser UV switching anyway, as I believe that they contain a lower-resolution version of the Genesis mesh than the one that the .CR2 exporter creates. So there may be fewer DSON format files that could be any use than you might think.