Question for the Ambassadors...
I know you guys are under DNA's, so without revealing any trade secrets or anything, I'm curious to know what your procedure for testing the new releases are in Poser. Do you go feature by feature and check off things as you go? Just test the features that you know and are comfortable with? How does that work?
I think it varies from person to person. For example, speaking hypothetically, I might try using the newest version of a software (not necessarily Poser) I am testing in regular usage doing what I usually do (some of which is pretty non-standard, as I love to experiment). If I run in to an issue that may be a bug, I need to replicate it, confirm it is the software I am testing, and then prepare a report.
For me, often times if I find a bug, it may have been already reported, and there may already have been an update, so then I need to get the update, install it, and see if the bug persists for me.
I can not speak for others though.
Sometimes, if someone mentions a particular issue, I will see if I can duplicate it, find a cause, or provide a workaround though - even if not a tester for given software, if I know the software well enough.
Hello Earl, well that's a good question.
Let us start from the beginning.
I play with Poser from Poser1 on a 1.44 demo disk. Remember those? :-) (Yes, I am getting old and older, LOL.)
Then bought every version that came out up to and including Poser8.
Initially Poser 8 had so many problems that I thought; "How is this possible?" Where can I report what I am seeing here?
So I filed detailed and documented problem and enhancement reports through the public reporting system, with suggestions "how to fix".
That was almost 7 years ago. My reports from back then must have been good enough for SM to ask if I wanted to become a beta tester.
Every cycle, the beta testers are reviewed. Some go, some stay, some new come in, depending on what the next release will be like.
Each beta tester is "competent" to "outstanding" in his/her department, and yes, we have our little disagreements too. :-) :-) :-) That is normal as we are all very motivated to get "our" issues fixed. :-) :-) :-) Ha-ha-ha-, and the small poor Poser team does its best in the limited manhrs available.
Knowing the software. Its strong and weak points.
Knowing the software "around Poser". Blender, Zbrush, Photoshop or Gimp.
Knowing your Operating System. => Inside out.
Having multiple systems: Example, I run Poser on 4 machines. 3 Poser11Pro and one Poser11.
Machines with different hardware like some with Nvidea and others with AMD cards, HD's and SSD's, and/or external drives.
Being able to search and replace dll's.
Having previous versions on other machines ready to cross-test.
Well, that's how I do it anyway.
And yes: Certainly in the beginning? Crashes, and crashes, and crashes. Sometimes so deep that on this Poser11 cycle I had to replace a PC that crashed so deep that I simply had to replace it.
Once a beta tester, (and this is personal) most of the free hobby time goes into testing. Little time is left for "art".
Every cycle, I build some items to test the new version. => Like the new dome that plays ground plane? What does it do? How to texture it? How to use it similar or . . . as the BB'shere?
Like the new rigging system to build teens? => You build a teen or 2 to test the functionality. => Always find "something", report, so you move on to the next new item, and test.
Some things get improved every week, some other things get broken. You are always searching: "Is it me? Or did the software do it? Because last week it worked? At least I think it worked. So you check the previous version on a second or third system. Back to Blender, did I make a mistake? Back to Poser, back to UVmapper, back to . . . Whatever you have in-house until you find the issue, document and detail it, and report it, so it can be reproduced at SM. Can it be reproduced? Only a reproducable problem can be fixed.
Some only see the "nice" side. Getting Poser for free.
But, damm, if you want to do it right? It is hard work, takes a lot of motivation and durability, and takes most if not all of your Poser time.
And to be honest? There are area's in Poser that I have not even touched yet. Just no time left. => But then I see that other beta testers are covering those area's. Oef.
Sometimes, I just have to force myself into Blender. Just to build "something" and not forget how that thing worked. :-)
Then you find something in Blender?
Ok, we have to see this in Poser, and before you know it, you go back and forward a few times, and the night is over and the sun is coming up. :-) :-) :-)
Best regards, Tony
I just closed off the PC's, read this post above once over, and it is 02:38 AM here.
WAY past midnight, WAY more past bed-time. LOL. :-)
But, tja, that's me.. :-)
Is that tile on your floor a procedural or image map?:smile:
Miss B last edited by
@eclark1849 Really Earl? :rolling_eyes:
bopperthijs last edited by bopperthijs
OMG, and I thought i was an poser addict! This is so over the top, you have to find a hobby:laughing:
@bopperthijs I'm not going to lie. I was looking out my window the other day at the woods behind my house and started thinking "I wonder how many vertices that would take?:smile:
bopperthijs last edited by
I'm on a vacation right now, and I'm still using poser in my spare time on my laptop.
Tony! Wow, it's so nice to have a face to put the name to. Great photo. Thank you for sharing that!
Do you guys use benchmark scenes to test Poser?
Do you guys use benchmark scenes to test Poser?
Not really specific benchmark scenes. I use a series of older scenes and compare results and render times with the previous version of Poser. If there are a significant differences, i investigate.
Yes and no; Depends on what is going on.
Over the years, I filed over 250 motivated and documented reports, each requiring a specific set of rules to reproduce. (Sometimes including a scene, a prop, a texture, or a complete video in the report to show/demonstrate the issue.)
Some are bug reports, some are enhancement reports, some are confirmation reports, and the list goes on.
The more detailed a report is, the sooner the Poser team can reproduce "in house" and implement the enhancement or find and fix the bug. (An issue can only be fixed or implemented if the Poser team can reproduce it locally.)
"Benchmarking" like checking render speeds, comes "in between", and usually as a comment attached to another report. (Speed goes up or down depending what is used and/or implemented) and as Wim said : It depends. Did the code of the node change? Is it calculated different? Did the light change?
Sometimes a report takes a only a minute to make.
Sometimes, it takes a week or more to find the exact "location" and reproducibility of a bug. (Or the "general public" profit for an enhancement report).
( I have been Posering from Poser1, and beta-testing for something over 7.5 years now. )
And sometimes, you simply have to wait for the next version to get your report in.
That's life, man-hrs are expensive and sometimes the priorities are elsewhere.
In 2011, I filed a report to get a pure : "txt to speech", knowing the implementing would perhaps be ready by 2020, perhaps even beyond.
Pure speed Benchmarking?
First investigate the changes and perhaps the speed increase or reduction is normal.
Best regards, Tony
ibr_remote last edited by
I am Ambassador, I hve not received any testing requests.
Same here ... could we get a status on this?
@Boni Nothing to get a status on. I'm just asking the ambassadors questions on how they test Poser for SM.
Generally, it will be an ambassador responding in the forum, rather than a dev; that's the "ambassador" part of our job, to free up the devs to work on coding.
Benchmarking: I don't usually test for render speed; only if I suspect a noticeable lag in render speed.
I do repeatedly use certain test scenes to check for consistency, any unintentional changes in behavior.
As an example of a test scene, I have a box with four windows, each using a different method of animating the same texture. I'll run a networked Queue render to check that the behavior is consistent, and run another to compare Superfly to Firefly. That scene's quad-video prop's only purpose is to facilitate animation test renders.
Another test scene is Roxie running along a ship's hallway. That scene uses dynamics and several special effects. Running a networked Queue render of that animation checks several things at once.
I have watched Roxie run down that hallway many times.
You write : "I sometimes wonder if anybody is at home at SM".
Don't forget that SM is in the middle of a reorganisation.
Basically : The existing USA SM Graphics department closed end november 2016 with a restart in Portugal where they are opening Job applications, and all this information is freely available on the Internet.
From public statements : SM plans to continue its Graphics program development with a new team.
In between : Poser ambassadors see it as their duty (and personal motivation and pride) to cover the gap and help out in the forums while SM concentrates on its restructuring.
Best regards, Tony