1. Welcome to CAST's newly designed and improved Forum

    Log in or Sign up and share the knowledge!

    Dismiss Notice

One of many weird wysiwyg performance quirks

Discussion in 'Technical Support' started by ilduendo, Jan 8, 2021.

  1. ilduendo

    ilduendo New Member

    Joined:
    Sep 22, 2020
    Messages:
    10
    Likes Received:
    0
    I'll let this one speak for itself. This is on an amd rx 5700xt (which by the way can't handle more than 10 fixtures at a time, otherwise frametimes lock to 100ms) on gtx cards the "trick" displayed in the video also works but not in the same way and with different limits.

    with nvidia cards I can get to 200fps and 300fps with the menu open, no need for it to be on top of the viewport.

    https://streamable.com/48inbj

    got many of these to show, and also some things to shoot. I've been performing many benchmarks since wyg performance is unacceptable and found lots of funny stuff. I'd be glad to get in touch with whoever can help to get to the bottom of this issues and actually have them fixed.

    cards being tested are:

    nvidia:
    gtx 970
    gtx 980ti
    gtx 1080ti
    rtx 2070

    amd:
    hd 6950
    hd 7870
    rx 480
    rx 5700xt

    I've done this tests accross multiple driver versions and guess what...
     
  2. Jason Gardash

    Jason Gardash Active Member

    Joined:
    Feb 5, 2014
    Messages:
    135
    Likes Received:
    15
    So many questions here,
    what app are you using to display the CPU and GPU RAM info on the left side. not standard Wyg display info.
    nice Thread ripper or I9 CPU btw. this will help greatly with just 10 fixtures on and nothing else enabled.

    So what are you trying to show us really? a thread ripper or 24core 3.0Mhz cpu with what I figure is a 1080ti or 2070 GPU running 10 lamps in a small circle with nothing enabled can give good fps. sure it does. show me a file with 4 video walls, 500+ fixtures half 3/4 with gobos doing a wide circle and strobe effect with shaders, footprint, materials turn on and the beam, flare set to something other than default. Also show us some environment setting used on the same system with same FPS then we have something to talk about. Right now your just trying to stir the pot without any info or content.
     
  3. ilduendo

    ilduendo New Member

    Joined:
    Sep 22, 2020
    Messages:
    10
    Likes Received:
    0
    you didnt understand it seems, check what happens with fps according to where I set the menu.
    with the menu out of the picture vs menu above the viewport yields different fps results. This is the quirk I'm talking about


    The VERY important part, is that gpu usage never reaches 100% even tho I have an absurd amount of threads to throw at wyg. This test is just to show the poor optimization wysiwyg has, that thing with menus shows qa levels unseen from a program that costs as much as it does. This kind of behaviour is unacceptable
     
  4. Jason Gardash

    Jason Gardash Active Member

    Joined:
    Feb 5, 2014
    Messages:
    135
    Likes Received:
    15
    Well I never run a pre vis with the menu open so still lost. But I get you your are going after.
    so I tried an experiment and seem to get the same thing. open another app and open a window and move it around framerate drops.
    Now I get your after more framerates and steady framerates. but even in video games the rates change pending on the scene and play action. cyperpunk 2077 has a tone of videos talking about this.

    As you are a new user to wysiwyg as far as I can tell you may not know that they have been focused on improving the shaded views for several releases. the upcoming release has even more coming as will the following and following.
    Wyg does not have raytracing yet but they are looking into it. you have to remember Wysiwyg is a specialised software program not a cad system with rendering capabilities on top of it like other programs out there. they also don't have a team of 60 programers in a room on a different floor from the tech support and ideas people. Cast-soft is a smaller company who also dealing with covid restrictions and trying to keep things moving forward. does it suck sure. it also sucks that I can make some pre vis stages and play around but can't go out and do a real show but hey what can you do. you sit and wait it out. I can say even with the restrictions I'm currently looking at the 2nd beta release cycle and still see improvement in the over all program. I still talk to the Cast guys every few weeks.
    So your stirring the pot in my eyes. we all been asking and after better renders. that's our duty to do. what the subscription entitles us to.
    But also have to give them time to create it. I must drop 10- 15 ideas a year and I'm just one of thousands who talk to cast requesting ideas.
    I will even say I think the unreal engine is a great new tech. but still I just ask and throw the idea out there and let them decide if it can be done.
    The usage of the program is changing. from design only to a general idea of the looks for the show to pre programming a show now it's become a major piece of sales pitch with renders and video snippets.

    Showing a video with a 24core CPU and higher end video card with nothing on the screen or any settings is just BS in my eyes and stirring the pot. do all the other features and show me the drawback of the program then you have something worth pushing to clean up.
    Fact i can do the same test with same results on other programs tends to tell me its a OS issue and not just an application issue.
    I can change one scene to another scene in Wyg and see the framerate jump around it comes down to the amount of workload the system handles much like the videogames and how they jump with different scenes from a cutscene to a chase scene to a open world rpg scene. I don't get 120fps solid across the board. I don't expect it either.

    You can always jump to another app. cost the same and from the majority of forum post I read, you will have same issues though in different scales or wording on them as well. as someone who invested in several apps over the years and use pending on who the client or designer may be they all have issues.
     
  5. ilduendo

    ilduendo New Member

    Joined:
    Sep 22, 2020
    Messages:
    10
    Likes Received:
    0
    You are not getting the point of this kind of test I'm afraid. I've done plenty of others, and I'm not new to wyg at all. The point of this kind of test is to see the artificial limits and to check gpu usage, and if they are software or driver related. In the case of amd cards, it's driver related. Gtx cards can actually reach the limit of 330fps

    now watch this,

    https://streamable.com/6byq1c

    don't even need to have geometry in order to see that wyg can't run properly on amd drivers (this is on amd's side their open gl pipeline sucks). So why is the Cast team recomending those gpus? when a six years old 970 works much better even just at 50% usage
    they should actually encourage their userbase to stay away from those gpus



    you can clearly see that gpu usage is pretty low, and clockspeeds also since this is the results with an rx 5700xt

    regarding geometry as long as whatever you import into wysiwyg is done properly geometry has little to no impact in performance, however complex geometry can completely tank it
    and video is just a vram heavy task, that's why we are resorting to testing with low amounts of fixtures and no geometry, since what we are trying to check are the artificial limits of wysiwyg in order to understand why gpu usage is all over the place. You talked a bit about games, and yeah sure, framerates will go higher and lower, but you should always stay at 90+gpu usage. You are looking at fps counts, while what I'm looking at is GPU USAGE

    I'm gonna give you an example, you specifically talked about cp2077. While I don't game, here's a little experiment that'll sure work and it's a great qa trick. Look at the sky, you'll see framerates go up by a ton, but gpu usage won't drop. This is the kind of tests we are performing with wyg, while it might seem completely anti-intuitive it's actually a good way to test how specific software handle resources, since what we have found is that wysiwyg is TERRIBLE at managing whatever resources you throw at it. Only the non real time rendering is great.

    https://streamable.com/4382k8

    this are some tests done with a 970, we were not checking gpu usage at the time since with those tests is where we found out that most of the time wyg can only use 50% of your gpu, then you could crank the quality slider until you reach 100% usage but that test should be yielding the double fps

    after this we decided to actually start seriously benchmarking and found LOTS of quirks. The menu trick I posted, fixes gpu usage issues most of the time (and only works in volumetric mode, not enhanced mode). I'll post proper material of this thing with gtx cards tomorrow
     
    #5 ilduendo, Jan 9, 2021
    Last edited: Jan 9, 2021
  6. Jason Gardash

    Jason Gardash Active Member

    Joined:
    Feb 5, 2014
    Messages:
    135
    Likes Received:
    15
    I can't speak for AMD cards as I never liked or trusted their drivers.

    I see what you're saying about the GPU usage but still your showing one clip with Wysiwygs video info and the others with a 3rd party app which I don't recognize partly due to the face I just don't stock 8 video cards in the closet to test out theories. I keep a spare video card in the drawer incase one of my 5 system video cards die and I have a spare and even that is an old GTX970.

    You may be right in that the video card is only using have its resources. To me if I can keep a consent 30-60 fps then I'm good. I'm not making a disney animated concert I'm showing a client what my rigs can do.

    But I continue to add to the pissing match. which could be out of me league or care factor.
    I say If it's something you feel cheated, something taken for granted or just think its done wrong, then as your subscription allows.
    Talk to the guys at Cast-soft. Dany and Dino heck even Gil I bet are always looking for good ideas to move forward. however they do tend to have strong knowledge of how their system works and where they like to take the program too.

    But nothing ever changes if you just post rants on a forum looking to stir the pot as you did with me.
    Do it my way. have an issue. Open the door to a discussion as to who and why and can it be done like this type conversations.
    Years ago another long term user passed this info along to me after I said something on a post and it was the best bit of advice I ever got on dealing with software companies. To the point I send questions about demo's to see how tech support respond. And well I may own multiple other lighting apps out there and use them if I need too. Wysiwyg is still my goto program just for that single reason. I have an issue I can email and within a few days the door open to a solution or a guide as to another way to accomplish that task is given.

    Wysiwyg is not a buy and expect it to work 100% of the time type program none of them are. Tech moves to fast for that. and they do a good job to keep up. Covid a wrinkle in things. Time never on our side in our industry but they keep releases coming and new features coming. To me none of the software out there has a render that is like Wysiwyg. they mostly look like cartoon beams to me. there's no real world looks to them. sure others may project gobo's better, or handle a video wall better but they still look like something real missing from the final render.
    so as I said to me and I bet most users if the video or render can spit out a good looking image and produce a 30 - 60 frame video who cares if it used 10% 50% or 110% of the power in the system. ity gave me what i needed and I'm not looking to make a disney movie type quality after all what client going to pay for that.
    I add that as they state in their system guides they did not have any rtx cards to test on. that i agree is a missed opportunity to a degree. with the ray tracing and what not but they are aware of that and are trying to rectify that, Covid has hampered that due to the current gear issues worldwide on availability. I think the Unreal type stuff worth looking at and have been talking to them about that. but i also drop several other request at same time. so pick the battles and let them do what they can with the resources they have.

    Send techsupport@castsoft.com an email with some links to what you have to show and open the door to conversation. never know a year down the road you may see a change that you can feel humble inside for contributing to it being released. you may even bond and form a great friendship with the guys at Cast-soft much like i did. which never have happened if it wasn't for that friend who saw a post and stepped in to say - just talk to the directly, why shout in an empty room.

    That's all I'm going to say about this. best of luck.
     
  7. Dany

    Dany Administrator
    Staff Member

    Joined:
    Jan 16, 2014
    Messages:
    968
    Likes Received:
    113
    Hello @ilduendo & @Jason Gardash,

    Thank you for all this information. It is a lot to absorb, so it will take some time, but I will look into all this and come back with a reply as soon as possible -- hopefully by the end of the week.


    Regards,
     
  8. Floriaan

    Floriaan Well-Known Member

    Joined:
    Feb 13, 2015
    Messages:
    516
    Likes Received:
    107
    I think it is very interesting what is brought up here. As in a simple test situation you can reveal more about how things are working then in a real world situation. In my experience we had related issues with a very well specd system were frame rates dropped below what was pleasant to look at (2.5 FPS), but the system performance graph indicating that the CPU and GPU weren’t used to their full capacities at all (like 60-80%).
    To me this indicates there is room for improvement and I think that is actually what Cast is after for their next release.
     
  9. Dany

    Dany Administrator
    Staff Member

    Joined:
    Jan 16, 2014
    Messages:
    968
    Likes Received:
    113
    Hello @ilduendo. Thank you for taking the time to share all this information, and sorry it took me a bit longer than promised to come back with answers. I will answer your points separately, so there are no misunderstandings, etc.

    Regarding your first point quoted above, I think it is safe to say that this issue should not be impeding your work in any way: after all, if you open a menu or a dialog "on top of" the Shaded View while this is simulating, it is because you need to make a change of some kind -- and surely a drop in performance WHILE you are making such a change is irrelevant. (I will confirm with Soft. Dev., but this most likely happens because the simulation and the dialog are processed on the same CPU thread, and the dialog gets priority over the simulation -- it MUST, because it is "above" the simulation on the screen, that's simply how CPUs work. It is likely possible to off-load the dialog processing to another thread, but coding thread management of this kind is quite the endeavour, and we would need more reason than this to start down that road, since the development cost would likely outweigh the gains.)

    As for your second point, the GPU not being utilized 100% has absolutely nothing to do with optimization, and I am sorry to have to say, but your guesses/statements here are misinformed. WYSIWYG's Shaded View engine uses an on-demand rendering system, not a constant rendering system that may be employed by other visualizers, video games, etc. (By "rendering" I am referring to the GPU processing frames that are then displayed on-screen, which has nothing to do with rendering via WYSIWYG's Render Wizard -- unfortunately, the terms are used interchangeably in the computer graphics world.) Our engineer who's been developing the Shaded View for 10+ years offered the following explanation:

    [WYSIWYG is] (and always has been) an on-demand render[er] as opposed to [a] constant render[er]. This means we re-draw the [Shaded View] when a change is detected. If the [Shaded View] is re-drawn before the next update is available, the GPU will be idle until the next frame is ready to draw. That is why the GPU usage can be less than 100% in some cases. Some 3D applications just re-render constantly even if the scene has not changed, this will show 100% GPU usage.


    I will provide more answers soon.

    Regards,
     
  10. Dany

    Dany Administrator
    Staff Member

    Joined:
    Jan 16, 2014
    Messages:
    968
    Likes Received:
    113
    We only really started recommending AMD GPUs sometime after the VEGA series was launched, so around the end of 2017. Before those, we recommended NVidia exclusively. This was based on benchmarks that we ran, which showed that the VEGA 64's performance was similar to its "NVidia conunterpart" (the GTX 1080). For the benchmarks we used real world showfiles. We have not yet tested the latest line of Radeon cards which were launched this year (such as the RX 5700XT) and as such we would neither recommend them nor be able to endorse their use.
     
  11. Dany

    Dany Administrator
    Staff Member

    Joined:
    Jan 16, 2014
    Messages:
    968
    Likes Received:
    113
    This is why we've been recommending geometry optimization for years now (and wrote about it extensively, here on this forum and on our website). As I said a number of times now, WYSIWYG is a lighting design and simulation/visualization app, so that is where its strengths lie -- NOT in parsing millions of polygons in realtime.


    I believe my previous reply, where I explained how WYSIWYG's Shaded View engine works, should answer the above as well.

    I am not sure what you are attempting to show with the video above... I am seeing 350+ beams visualizing at an average of 35FPS; the framerate drops slightly when the camera is moved -- but that is perfectly normal and expected since the GPU now has more work to do; the framerate then goes up when the camera is positioned such that the beams are seen from the side as opposed to "head-on" -- which is also normal, because with the beams like this they require less pixels to display on screen, which means that the GPU has less of them to "fill", which in turn means that it can do the work faster; finally, the framerate then drops once more when the beams are pointed "into" the camera -- which the "reverse" of what I just explained.

    I do have a question here, if I may (in which I echo @Jason Gardash): any framerate above 30 is considered "realtime"... and this is what you are achieving (at least in this video)... so why does it matter what the GPU is doing, as long as you are able to program your show in realtime?

    EDIT: An additional question: would you WANT your GPU to be utilized at 100% from the moment any Shaded View comes on-screen to the time it's gone? The stress from that could easily cause your video card to last only about as long as its warranty. (I have no way of knowing, but I've always had the suspicion that the warranty period for electronics of any kind is determined by letting the device run "at full tilt" until it stops -- and however long it lasts, that's the warranty period.)

    Thanks,

    Dany
     
    #11 Dany, Jan 19, 2021
    Last edited: Jan 19, 2021
  12. Dany

    Dany Administrator
    Staff Member

    Joined:
    Jan 16, 2014
    Messages:
    968
    Likes Received:
    113
    @Jason Gardash, thank you for jumping in here and the advice you offered to @ilduendo -- especially about reaching out to us in Tech Support for problems like this. In this case though, posting on this Forum was not necessarily inappropriate, since it is CAST's Forum, and I believe the intent was to "get a conversation going" -- not only with CAST staff, but with other users such as yourself. That said, @ilduendo, we can continue this here, or you can email support and ask them to pass your email to me (mention this thread, please) and we will go from there.

    Since the COVID situation was mentioned, I wanted to say that affected CAST the same as it did the entire entertainment industry, and the entire company working from home for the past 10 months, and with reduced hours, has not been great for business in many ways. Many things that we had planned for 2020 fell through because we had no choice but to let them do so, but the biggest issues here were lack of access to certain office systems (which simply could not be brought home by our staff to use there -- which resulted, in many cases, in stinted development and testing) and the inability to acquire new hardware for the same (i.e. testing and development). Even with all that though, we delivered a new version of WYSIWYG with a significant number of very useful new features, enhancements and libraries, R46 (which will feature the most requested feature of the past two years -- MVR importing) is on its way, and R47 is already being planned for the summer.


    Thanks for understanding,

    Dany
     
  13. Dany

    Dany Administrator
    Staff Member

    Joined:
    Jan 16, 2014
    Messages:
    968
    Likes Received:
    113
    Hi Floriaan. I believe my first post from earlier, where I explained that our Shaded View engine is an on-demand system, answers your comment, and I'll leave it at that -- but I am happy to answer any other/follow-up questions, of course.
     
  14. Floriaan

    Floriaan Well-Known Member

    Joined:
    Feb 13, 2015
    Messages:
    516
    Likes Received:
    107
    Hi, your answers are very helpful. It gives a much better insight in what to look for when frame rates are low. My problem might be VR-related rather then general. But it is disappointing to see such low frame rates, when the GPU is being used at far from full capacity.
     
  15. ilduendo

    ilduendo New Member

    Joined:
    Sep 22, 2020
    Messages:
    10
    Likes Received:
    0
    Wow, I've been ootl for a couple of months since some other projects came up. I'm gonna keep it short and simple for time's sake.

    First of all, I'm not expecting 100% gpu usage all the time. I already understand how the wyg engine works, a trick that I always use is to have a "dummy fixture" on the background moving at max speed in order to trigger the engine to start rendering. You can already observe that in the video.
    While "30 fps" is considered real-time, for programming and operating a response time of 30ms is too slow, ideally it should be 10ms (90fps) but close to 15 is fine (60 fps).
    The issue comes when I'm doing 24fps and WYG is using 10-50% of my gpu, and even reducing the quality won't increase fps. It will just decrease gpu load.
    In an ideal world, I would program at the lowest quality setting possible in order to achieve 100ish fps, and then render at 30 at the highest quality possible, specially since most of my shows are time-coded.

    Currently if I'm on the highest possible settings, my fps are 35 and gpu usage is 15%; dropping quality settings will only decrease gpu usage, but fps will stay the same.
    You may say now, "well 35 fps are acceptable". Issue is that when gpu usage is 100%, fps=20 if I drop quality settings gpu usage will drop and fps=20 still.

    For what I've tested so far this issue is mostly related to single threaded performance, correct me if I'm wrong, surely your engineers will have better info. Regardless of that, the quirk I posted about which is the "menu trick" (have some menu open while rendering on live mode) seems to weirdly help to balance the load across more threads.

    I wouldn't mind at all doing a 30mins screenshare call with some employee to show all of these stuff. Again, not to bash the company, but it's a pretty expensive tool, it should behave like one.
    I understand that your engineers might have x amount of time working on the engine, but we gotta understand that single threaded performance won't increase much in the future and at best I could expect a 100% increase in performance from top notch cpus in the market where if I'm getting 20fps... it will yield what, 40fps then? and 30% gpu usage?

    Imagine having an rtx 3090 and wyg only being able to utilize 30% of it, because of engine limitiations (there's no single thread that can feed a 3090 in existance)
     
    #15 ilduendo, May 26, 2021
    Last edited: May 26, 2021
  16. ilduendo

    ilduendo New Member

    Joined:
    Sep 22, 2020
    Messages:
    10
    Likes Received:
    0
    I wouldn't mind helping you at all getting better framerates, have you tried setting up a "dummy fixture" in the background and having it run at full speed? just movement, this is what starts demand to the engine and that's how I reach 200+ fps with no lights on.
    With issues coming from single thread performance it gets tricky but some things can be done about it.


    and again @Dany regarding this response

    Hi Floriaan. I believe my first post from earlier, where I explained that our Shaded View engine is an on-demand system, answers your comment, and I'll leave it at that -- but I am happy to answer any other/follow-up questions, of course.

    understanding that this engine is "on demand" is the most basic thing, most of wyg users should be past this by now. What you need to start addressing is how to "demand the engine" in order for it to respond as we'd expect. As I'm explaining that method to floriaan, which is pretty easy to do and explain (I've never got this explained by anyone from cast and I've never seen 'em do it to the point I'm starting to think you are not much aware of how this software works besides what some coder is able to tell you)

    And I'm not even going to get today into why you shouldn't have an on demand engine running on vr, this could be hazardous for some folk.
     
    #16 ilduendo, May 27, 2021
    Last edited: May 27, 2021

Share This Page