Poser 11 SR7 is available



  • @vilters I have seen two types of malfunction in Poser. First, if you turn up the graphics just a bit too much, the SuperFly process will get wedged. It's an easy fix, start a terminal and kill the subprocess running the render. The second has to do with the mouse. There is a danger zone near the edge of the screen, which is oddly enough where the menus are located. Sometimes, the mouse will send off a weird event, and poof. Doesn't appear to be OS related, I had the same features on my Vista PC and now my Mac Mini (got tired of virus scans and the interminable daily reloads of the entire operating system, so no more Windows, ever). Otherwise, Poser is pretty stable for me.



  • @vilters Here's the thing. I've always used Poser on my Mac. If anything went wrong with it, and it rarely did, I could fix it. And I always knew where the files were because I knew where everything was on my Mac. Now, I'm running Windows 7 on a Dell Laptop. I've been running Poser on a Mac since version 2. This is the first time I've ever had to use a PC to run Poser. It took me a couple of months to figure out where the new content I buy goes. Add to that that i was quite happy with the way PP11 was running. It wasn't giving me any fits or anything. SR 8 was the first update I installed since I bought the program about a year ago. But yeah, ever since I updated, Dawn keeps taking a powder any time she gets a mind to, and now Poser either crashes or hangs, depending on what I'm trying to do, and that's mostly rendering with Superfly or trying to run a sim in the Cloth Room.



  • @eclark1849 We have to take step back into yesteryear to understand the mess that is the PC. In the beginning of time, you could only see 640K of the first 1MB of RAM on a PC, the rest was just ignored. Then, one day IBM thought it was a good idea to add a chip that would redirect memory access to this upper region into the peripherals to speed things up. This is the point where I would like to travel back in time and say "Nooooooo!!!!" Things worked pretty well, because they had complete control of mapping in this upper region. A side effect of this control was that they did not build in any, and I mean ANY, way for the cards to communicate with the communications controller. Nothing. As long as IBM had complete control all was well. Then, they lost control. It was now possible to initialize your network card, and have the hard drive reformat itself. What a mess. To add insult to injury, people started loading hardware drivers into the upper memory regions, which sometimes were loaded into the graphics card by mistake. There was no way to fix this, for as you recall there is NO way for each card to register memory use (no out of band signalling). Eventually, Microsoft forced people to stop loading drivers in this upper area, but the cards still unfortunately, suffer from this early disaster.

    In a nutshell, graphics are hard, and it's not always the software's fault...



  • @tburzio
    PC memory architecture has changed since then, specially in 64bit versions.



  • @semicharm No, not in this important respect. Intel likes to let you think it has, but it still has this problem. In fact, they went to a great deal of trouble to make you think it had. This is why Apple is about to finally dump the whole x86 architecture and use their ARM chips.



  • Did you know that some people are unaware that the cause of the common computer virus is the removal of the length of the executable from the executable header in the early days of Windows? This is called a cavitation virus, because you can confuse the link loader by adding a second program in the excess allocated file space on the hard drive, or cavity. Yeah, it's really that simple, but a complete mythology has grown up over the years to try and explain something so simple. Microsoft knows.



  • @tburzio
    PCs have different operating modes for compatibility. Most of them are likely to be abandoned after legacy BIOS and DOS support are finally dropped.

    And no, Macs are unlikely to make that transition again. At least if they're smart and care about retaining their remaining user base. ARM processors have come a long way, but there's no way they'll be able handle x64 Mac apps through emulation with acceptable performance or head on with an actual ARM port against the original x64 version.



  • @tburzio

    Microsoft has a weird habit since a long time: one version on two is to avoid at any price.
    Example of those: WinMe, Vista, Win8.xx
    Most of the time, these versions don't handle correctly the PC's resources when it's a little too much overloaded, for example with programs such as Poser.



  • @tburzio said in Poser 11 SR7 is available:

    @eclark1849 We have to take step back into yesteryear to understand the mess that is the PC. In the beginning of time, you could only see 640K of the first 1MB of RAM on a PC, the rest was just ignored. Then, one day IBM thought it was a good idea to add a chip that would redirect memory access to this upper region into the peripherals to speed things up. This is the point where I would like to travel back in time and say "Nooooooo!!!!" Things worked pretty well, because they had complete control of mapping in this upper region. A side effect of this control was that they did not build in any, and I mean ANY, way for the cards to communicate with the communications controller. Nothing. As long as IBM had complete control all was well. Then, they lost control. It was now possible to initialize your network card, and have the hard drive reformat itself. What a mess. To add insult to injury, people started loading hardware drivers into the upper memory regions, which sometimes were loaded into the graphics card by mistake. There was no way to fix this, for as you recall there is NO way for each card to register memory use (no out of band signalling). Eventually, Microsoft forced people to stop loading drivers in this upper area, but the cards still unfortunately, suffer from this early disaster.

    In a nutshell, graphics are hard, and it's not always the software's fault...

    This reminds me of the time of 386^Max and Qemm...


  • Poser Ambassadors

    @tburzio

    With some figures, that load a TON of 4K textures like diffuse, spec, bump, normal, displacement, transmaps, times the number of material zones, it is easy to get to the max RAM limit, or the max limit of any video card.

    I forgot : Times the number of figures in your scene.. LOL.

    As you can calculate:
    There are a LOT of 4K textures to load and manage, and that's even BEFORE doing the calculations start what all the nodes are asking for in the material room.

    It is like a car, overload or overspeed it, and you run into problems.

    For FireFly, we only had RAM limitations, now for SuperFly, we also have card limitations.

    Ha-, this is the area where RMZSSK comes in. LOL.
    Translated it means: BTB and KISS and get a better result in the process.



  • @tburzio If that ever was such a thing as a "cavitation virus", google can't find any reference to it and would be defeated by a checksum and other security measures.



  • @Y-Phil Yeah, it usually takes another version to fix the problems created by the previous one, then the next will change a bunch of things and start the cycle again. :/ Microsoft has basically made their users open "beta" testers for decades.



  • @semicharm Well, as i said , PP11 either hangs or crashes when I'm using the Cloth room or rendering. Except when i'm using Cycles shader nodes. Then it renders fast as crap through a goose!

    0_1512147520439_9f971838-5d18-4b63-ad98-b0ee57e5cd81-image.png



  • @eclark1849
    I never got around to learning the cycles nodes, as I still use some of the features that Superfly doesn't support and didn't feel like rewriting all of my shaders either.

    BTW did any of my suggestions help?



  • @semicharm Sorry haven't had a chance to try yet.



  • @vilters said in Poser 11 SR7 is available:

    With some figures, that load a TON of 4K textures like diffuse, spec, bump, normal, displacement, transmaps, times the number of material zones, it is easy to get to the max RAM limit, or the max limit of any video card.
    I forgot : Times the number of figures in your scene.. LOL.

    I have a question about this. Do all these 4k textures slow down Poser's performance in the Pose room (in Preview mode) even with hardware shading disabled, a max preview texture size of 512, and items that use trans-maps set to wireframe display? And even if I've deleted all normal, bump, displacement, and specular maps in V4's skin shaders and let EZSkin set up procedural bump and spec instead?

    By "performance" I specifically mean using parameter dials to adjust figures' poses and expressions, NOT rendering. With two V4's in a scene and only a few infinite lights, and with no other apps running on my MacBook Pro (w/ 16gb RAM), Poser's response to my efforts to turn parameter dials starts to slow down after about 30-40 minutes of trying out various poses and expressions.

    I had thought I'd ruled out large textures as being the culprit by using the methods indicated above, but maybe I'm missing something? Does Texture Cache Size play a role? (mine is at the default of 500mb) Would it make a difference if I didn't use texture shading in Preview mode at all and instead used flat shading? It would be a bit depressing to try and bring my characters to life if I had to look at them that way, but it would be worth a try if it meant I could use Poser for longer than an hour or two before it either stops responding or crashes!



  • @perpetualrevision just a thought: how many renders does your setup keep in the window? I keep mine down to about 10. If I do large renders and have a few built up it slows Poser a bit for me.


  • Poser Ambassadors

    @perpetualrevision - I've found it's number of visible vertices that slows down preview for me more than any other factor. Basically my understanding is that anytime anything is changed in the scene Poser runs through the numbers for every mesh, so the more data it has to look at = slower response. So I use visibility plus Groupings a lot.


  • Poser Ambassadors

    @perpetualrevision said in Poser 11 SR7 is available:

    @vilters said in Poser 11 SR7 is available:

    With some figures, that load a TON of 4K textures like diffuse, spec, bump, normal, displacement, transmaps, times the number of material zones, it is easy to get to the max RAM limit, or the max limit of any video card.
    I forgot : Times the number of figures in your scene.. LOL.

    I have a question about this. Do all these 4k textures slow down Poser's performance in the Pose room (in Preview mode) even with hardware shading disabled, a max preview texture size of 512, and items that use trans-maps set to wireframe display? And even if I've deleted all normal, bump, displacement, and specular maps in V4's skin shaders and let EZSkin set up procedural bump and spec instead?

    By "performance" I specifically mean using parameter dials to adjust figures' poses and expressions, NOT rendering. With two V4's in a scene and only a few infinite lights, and with no other apps running on my MacBook Pro (w/ 16gb RAM), Poser's response to my efforts to turn parameter dials starts to slow down after about 30-40 minutes of trying out various poses and expressions.

    I had thought I'd ruled out large textures as being the culprit by using the methods indicated above, but maybe I'm missing something? Does Texture Cache Size play a role? (mine is at the default of 500mb) Would it make a difference if I didn't use texture shading in Preview mode at all and instead used flat shading? It would be a bit depressing to try and bring my characters to life if I had to look at them that way, but it would be worth a try if it meant I could use Poser for longer than an hour or two before it either stops responding or crashes!

    In the pose room, preview mode, the texture size used is the one you specify in Preview render settings. If you have set it at 512, it should be okay.
    A thing which does slow down the pose room a lot is multi-layer transparency. If you have that one, it will slow down the performance a lot. Turn it off when posing, only use it for preview rendering or when you are adjusting materials.
    Also having your render target set as Superfly (even when not rendering) can slow the Poser room down. Set it to Firefly or Preview

    I have no real problem getting 10-20 clothed figures in a scene. Dials do slow down, but still usable. What that happens i switch to another display mode for the scene

    But i have to admit I have a PC with i7-6850K 3.6Ghz, 128GB of memory and 2 GTX 1080s in it



  • Hi,

    I'll probably put this in a bug report, but I thought it might be good to let others know. I'm encountering a very weird Python error where Poser crashes when I try to delete things via Python, but not if I do it by hand in the GUI. Literally these two lines crash Poser:
    sel = poser.Scene().CurrentActor()
    sel.Delete()
    in the Python shell when I have a very simple prop selected. This means I'm encountering fatal errors in the script I'm building and testing, errors I can't do anything about. I have only had this problem since upgrading to 11.1.0.34759


Log in to reply
 

Looks like your connection to Graphics Forum was lost, please wait while we try to reconnect.