Hi.. promise not to laugh? : I have an ATI card with only 16MB of memory on it (yes.. only 16) .. this card has served me well and seems pretty OGL compliant, I dont really play games, but I have been able to run both Quake3 and RTCW (both Opengl) without a hitch.. I'm guessing the above red sphere (where the manipulator should be) is an OpenGL problem, I'd just like confirmation really. Well actually I'd like someone to say "no its not OGL, heres what you do" , but I need to know either way.. Pity really DS looks good to me but if I cant see the bits whilst Im posing I cant really use it .. Anyway thanks for any help on this.. Best Wishes Barrie. (BTW I do have the latest and final drivers for my card)

Not to worry- it seems like some kind of bug-artifact that comes from certain Poser files. I've had the same thing happen with some of my Poser file imports. Some Poser files seem to contain these Spheres, which in Poser are invisible, but are there sort of like Body Handles or other posing mechanisms, and the initial Alpha version of Daz Studio is making them visible. The same kind of thing happens with Poser files that I have Z-Tooned using Ockham's Python script. DS makes the normally invisible "control balls" - visible. It's an Alpha bug and something DAZ can address in their Poser file import code. It's just one of a number of things people will likely discover- and then DAZ can adress as an "issue"- and fix. That's why its an Alpha release and why DAZ encourages people to find and report these bugs- so they can squash them!

Uhm... this doesn't look like a Body Handle or Control Ball (like Sara has hanging off of her ears and breasts). Notice the blue and green rings around it? It looks like the D|S editor window rotation tool, being drawn with a sphere in the center, which shouldn't be there. So yes, it looks like a driver issue to me. It might can be fixed (or worked around) in the D|S code in a future update. It might require a new OpenGL driver for your card to fix it... but there may not (ever) be a new one for that card, so it might eventually require a new card.

...just to clarify... the red sphere is an artifact of the D|S editor window rotation tool itself, the Body Handle or Control Ball is much smaller (and green, if it were visible). This image shows what your view _should_ look like, without the driver issue.

...I made the body-handles visible (the small green balls).

Oh! You mean it isn't meant to look like that (another oldish ATI card here)?

Damn, looks like a new card for me then (no more driver updates for my card) ;( .. well maybe not .. I tried using wireframe drawing including lit wireframe and they all work fine.. its just the shaded modes that screw up the manipulator thingy. I had a go at posing in wireframe (ewwwww) and it all seems to work fine but I found that I didn't really like the direct manipulator tool very much anyway so I may just have to get used to using dials (ewwwww again Thanx for your advice all.. Best wishes Barrie. PS it wasnt just Sara it was low res mike and vicky that came with DS as well.

It must be an older ATI bug. I've got the same thing. I don't remember the specs on my video card.

It occurs on Matrox cards too. And it appears on .daz figures in the supplied content (but in white), so it's not the Poser import. Rob W felt it was related to lack of memory on the OpenGL card (I've 32MB), but I didn't get him to give guidance on how much was enough.

Also in my case it remains transparent if I only have 1 (smallish in file size), add a second or use a larger character and it goes red or black - always same colour for given characters.

My hunch is that it's a coding error in Studio (Matrox OpenGL implemenation is used in many workstations), but if not it's unlikely to get fixed per se, as the response would be a simple (from Daz perspective) upgrade your card/driver (not possible in my case).

However, all may not be lost - there have been requests from the outset for those "control balls" to be made optional, via a prefrences or a hot key, from those users without this bug. They just want to be able to look at a clean image in the scene window. IF that enhancement was added, then the solid spheres could be hidden by those of us experiencing them, and adjustmenst made using the dials. Otherwise, as indicated, even using the dials is not an option - unless you like making adjustments to hidden actors :-O

Rob would know better than I would, so he may be right on the memory thing and more memory is always a good thing ;). You might wait a while to see if they can work around it, but if you're going to end up upgrading, I'd look for a card with a chipset by ATI or NVidia with 32mb bare minimum but would really recommend 64mb or higher to ease your future pain.

..then again, I don't recall which card Veritas said he had, but I think it was fairly recent and he's apparently having similar issues, so it may end up being a driver problem (not a memory one) afterall.

{Sssssh, this old forum software! Attempt 3 - hopefully not eaten this time... } OK, did some Googling... Transparency is an issue with graphics packages it seems, particularly if they support ray tracing correctly. It puts a large load on the graphics card to display alpha transparency. (There is a kludge used in games to get transparency to render easily, but it impacts lighting results - so isn't the choice in 3D graphics packages.) Result may be transparent surfaces displayed as solid surfaces. Seems to fit. Per Alias' support pages for Maya, cards without Hardware Overlay planes give poor performance in OpenGL on Maya. Their sample list of cards is interesting as it correlates exactly with cards peeps are reporting having this problem with Studio: - NVIDIA TNT/TNT2/GeForce/GeForce2 - ATI Rage 128/Rage 128Pro - Matrox G400 - etc. All this is circumstantial of course, but it looks as if Studio may depend on overlay for rendering the "control balls" - it would certainly seem reasonable. And then any card resorting to software Overlay would have a harder time of it, whether due to lack of raw processing power, or card memory I was not able to glean. [Agreed new cards are not that expensive, even for PCI only systems. But my problem is a Matrox G400 3D-Flex card tied at the chip level to the expensive video capture card in my system.]

It has nothing to do with content. Memory can factor in, but the likely culprit is a lack of support, by your video card, for particular OGL extensions... namely a transparency buffer. Partial implementations of the OGL spec certainly don't help either, especially considering we're writing against the spec. Will we work around the limitations of the card? We've already tried to include a number of fallbacks, in the event an extension is not supported by the card, and we'll continue to refine them as needed, but there comes a point where a particular card (or series of cards) just won't cut it. D|S creates a 'log.txt' in its root directory. Amongst other things, recorded in that file are the extensions your card supports, and which of those D|S is using. Reporting the issue and including that file will help us identify the problem.

FWIW, at home, my current primary machine has a GeForce4 Ti4600 128MB... I've not had a single problem. I also have a PIII 733MHz Dell Inspiron 5000e (laptop) with a Rage Mobility 128 M3 16MB, which has been relegated to continue the rest of its life as a glorified email client, but I see the same widget display issue on it. At the office, one of my machines has a Radeon 8500 128MB... and with each driver, new/different problems occur in ALL applications I use which utilize OpenGL, not just D|S. ATI's drivers have been... well... annoying, to say the least. I'm in the process of migrating to a new machine at work... one with a GeForce FX 5600 256MB card. Like I said, FWIW.

-Rob

cross-posted.

Thanks for the tech info Rob. What really sucks is some cases where.... it's bad enough to not support some OGL spec, but it's worse when they don't support it, but claim they do and provide some lame fallback (not sure if this is the case here, but that's happened to me before).

BTW Rob, while I (hope I) have your ear... have you seen the editor-window manipulation tools in C4D? Their translation tool is nearly identical to the one in D|S (cones on the ends of the axis). I think it would be a great improvement if the rotation tool in D|S was identical to the one in C4D as well (little spheres on the ends of the axis) along with the scale tool (little cubes on the ends of the axis). This would also at least fix this one issue ;).

In designing the UI, I've gleaned inspiration from several applications. I'm a fan of BodyPaint (same UI), myself, so... yes I have certainly seen Maxon's widgets. That said, our 3D manipulation widgets are not finished, not in the least. There is plenty of UI not yet implemented. Although I do like the simplicty of C4D/BP widgets, I also like some of the feedback provided by 3ds max 5 style widgets, but there must be a balance between 'enough' and 'too much' visual feedback, for certain.

-Rob

...again, the yet unimplemented portions of the UI. If you haven't already, please submit this to the db. -Rob

Looks like I'm going shopping for a GeForce FX 5600 256MB! My Matrox and ATI Radeons work great for my other work, but I think I'm now going to go buy a completely new workstation just for doing DAZ Studio projects!

BTW- I have Matrox G400 64MB cards on two workstations and 1 ATI Radeon 128MB on another. Come to think of it, I believe the SOLID ball problem is on the Matrox, but not on the Radeon. However- I haven't upgraded either driver for almost a year- because they are such stable and reliable cards- especially for my other business projects, but I think I would now like to build a DAZ Studio specific 3D rendering platform. I really think DS is the ideal "Middle Ground" between all my other Poser-Vue-Bryce projects and Poser-Lightwave-MAX projects.

Rob, Thanks for the response. Understand impossibility of featuring support for every card's OpenGL issue - and in this case if it is indeed lack of hardware overlay planes, there's probably no real fix, at best just lifting the level of pain, until it bites anyway at a higher level of scene complexity. But what about the idea of just making the controls optional via a Preferences setting? That way Studio would still be usable on all of these cards. Of course the option would have to prevent all calls to overlay routines, not just make the controls entirely transparent ;-) But then Daz' message on OpenGL would be that you need a later OpenGL card implementation to fully support mouse manipulation of scense, vs. current message which has to be, you need later OpenGL card to even use Studio.

I would of thought that being able to play "quake 3 arena" and "return to castle wolfenstein" without a hitch would be a pretty good test of opengl compliance, but obviously they dont use transparency ( really ? ) .. I hate spending money :( ... Bah humbug.. Barrie.

I hope it'll be fixed too. Though I haven't got the problem on my main computer, I DO have it on my laptop (and that laptop is only 1 year old). Changing graphic cards in the laptop is NOT an option, so... Please, I want to play with D|S when I'm on camping and stuff too...

Partial workaround... Click on the "compass direction" icon on the toolbar (2 double headed arrows in a plus sign). This replaces the (opaque in our case) sphere with an axis-only move icon. Kinda big and distracting - but at least it's transparent, so the actions of the dials are visable... Meanwhile we ALL need to submit this as a bug, 'cos they claim to be fixing bugs based on volume of reports per bug (shudder) - way too much like CL's Poser5 approach (BIGGER SHUDDER) Trouble is I for one can't submit bugs, OS Platform is a required field with only one choice - "Not Set" - so it fails entry validation.

I havent been able to use D|S because my graphics tablet is useless at controlling it , even worse than poser its like it only wants to move right, even though Im moving it left .. Didn't they used to have to pay people to test programs for them ? It seems like users these days need to put in such an effort to get the programs to wrok properly.. I resign from any beta testing in future (unless I get payed).. Barrie.

sorry my machine doesnt conform to your program ... but my machine does conform to my operating system ... does your program ? gets ready to rant ... then stops himself ... Barrie. (no harm meant)