Jump to content

jweston

Member
  • Posts

    133
  • Joined

Posts posted by jweston

  1. 4 minutes ago, bbudzon said:

    We do not have any, but this has been discussed in the past. I think one issue we kept running into was users wanting their files kept private. A lot of the files we get from users are on NDA and cannot be shared with other users, but are used for internal testing.

    I can absolutely come up with some weird designs to send over. In all honesty they are not as "pretty" as the Sponza demo file. But that is purely by design. At least in our use case, we are trying to get the fastest frame rate, with as much realism as possible. Does this mean we get to use the nice new haze? Sadly no. We just need to have the lights dim, wiggle and show gobos with as much accuracy to real life as possible. Our goal is not photo realistic renderings, but something that closely resembles the timing you would expect in real life on the actual rig.

     

    I will try and create a small, medium and large show file to send over your way that can be distributed to anyone.

     

    10 minutes ago, bbudzon said:

    Most of our developers run on fairly minimal machines. Tech Support and Marketing have access to one "beast" machine that we often take to tradeshows. This machine was a beast when we built it, but it is now becoming dated. I'm not sure the CPU/RAM that it has, but we had 2x1080Ti's in SLI in it at one point.

    Where is the tip jar that I can add money too to get you guys good hardware? While I know the current discussion is that the software may not currently scale perfectly with hardware, I would love to push the need to have something that scales better. 

     

    12 minutes ago, bbudzon said:

    No, but I like this idea a lot! I'm not sure how we'd go about approaching it, but that's neither here nor there 😛

    Cannot say I know the best way to test this either, but I do know with other programs this is a much bigger sticking point. And in following this, knowing if a different cpu architecture is better than another, or cores vs clock speed type discussions.

     

    Vision is arguably less about data and planning, and purely about speed and looks. So knowing how to get the most out of that is really the only thing that matters to us in Vision (maybe others disagree?)

     

    17 minutes ago, bbudzon said:

    Those limiting factors are not time and money. I know this is an extreme example, but passwords are very well encrypted. So much so that the fastest computer in the world would take years/lifetimes to crack it. The "issue" here isn't necessarily the hardware. It is the algorithm that is used to crack this password. For example, a dictionary attack may be faster than brute forcing. This is all on the same hardware, but the software imposes an upper limit on "how quickly the password can be cracked".

     

    Taking this conversation to Vision, look at Vision 2018 vs Vision 2019. It did not matter how much time/money/hardware you threw at Vision 2018, it just ran like garbage compared to the same machine with Vision 2019. So, while it may seem like the limiting factors of performance are time/money, this is only true to a certain extent. Eventually, you will hit an upper limit of the algorithm itself, and the issue is no longer hardware but the software design.

     

    One thing to keep in mind as well as that it was somewhat intended for these features to be shut off for real time renderings. The main reason we keep these features around is for "High Quality Render Movie/Still".

     

    Lastly, I do not disagree that Vision performance for real-time renderings needs to be improved. There are a few areas we can look at, but the one I've got my eye on is the physics engine (which is what handles panning/tilting fixtures, moving meshes related to DMX XForms, etc etc).

    Fair enough, but one would expect in that extreme case  that the amount of time it takes to crack a password with an old Pentium III CPU vs a new AMD Threadripper 3390x would be significantly lower.

     

    Obviously Vision has been getting faster. However lighting, like Moore's law seems to be getting complex just as fast. With all the current multipart fixtures things have gotten big fast.

     

    I can get over all of the trials and tribulations (see fixture orientation, dmx transforms and the like...) but allowing the hardware to scale "better" with hardware should be a must.

     

    I hear by place my vote to let you guys focus on making the software "solve passwords better" haha. If you guys improve that portion of the software, then I can throw hardware at it. I think it is perfectly acceptable to accept that if I want it to run faster I just throw gear/money at it. Currently I don't feel I can do that with much success.

     

    Then once all that settles we can all deal with MVR and GDTF. 🤣

     

    (Steps off soapbox)

    • Like 1
  2. So besides the obvious "What hardware can I buy to make it perfect?" type question I want to be more more inclusive of data analytics and actual testing.

     

    1) I know that there is the Demo file that Vision comes with, but what are the chance of having a few "user created" scenes that we can send out for testing purposes? I would LOVE to see a data table of the same file, used across a bunch of different hardware and settings.

     

    2) What types of setups do you guys test on at Vectorworks HQ? Do you try multiple types of setups from minimal to absolutely insane?

     

    3) In a lot of Graphics heavy programs or scenarios there are very specific requirements to get the most out of a system. That includes even down to the exact graphics driver you are using for a given card. Has any testing, data or thought been put into trying to figure that out?

     

    4) While yes there are limitations to the way a software can scale too, I would think those limiting factors would be money and time? In my opinion I would like to see improvements made in the ability to get large fixture heavy shows working as fast as possible, and then go back and add in the fancy features. In most cases I end up running my machine at 1024x768, turning off every feature the program has just to get the lights to flash all at one time when I hit the button. Thus all that time put into making those features is a complete waste. Knowing that it is possible for me to buy a 64 core processor, with dual 2080ti, 256gb of ram and then overclocking everything, but not knowing if that actually helps me at all is painful.

     

    Lastly, if there is anything we can do to help test this sign me up. 

    • Love 1
  3. Having just gone through this process myself I will try and offer a little help that worked for us.

     

    Go through your Vectorworks file and figure out where you want the pivot point to be. (in our case I created a simple box symbol symbol, and made it a lighting instrument) This allowed me to leverage a worksheet to make a nice list of all my pivot points that I could print out. (pivot point name for organization, and then X,Y and Z position - in inches based on document units)

     

    Exported that list to Excel. Reason we did this was so we could swap Y and Z positions before entering them into Vision (as they have different coordinate systems) and that always gets confusing to remember.

     

    Then in Vision we created a New layer in the Scene Graph for each rotation transform we wanted. For each new layer, we named them accordingly (ie. Truss 1 Transform Rotate) and adjust the X,Y and Z position of the layer to match with the pivot point we figured out from Vectorworks.(this is where having the pivot point figured out already sped things up, kinda)

     

    For each transform we exported a .mvr that only included the truss, objects and lights needed for that transform. You merge each .mvr in to your file one at a time. After each import you can drag the .mvr layer "into" the associated layer you created to nest it inside the transform layer. 

     

    Adjust the DMX transform data as needed in your high level transform layer to get the rotations as you need them, and the nested layers follow suit.

     

    We found it helpful to export our Truss in a vertical orientation from Vectorworks using the same pivot point we wanted. That way we could default the DMX transform channel in the console to 50%. This allowed us to rotate the truss both positive and negative directions without needing to nest yet another dummy layer for transforms.

     

    I hope this helps.

     

    I hope that there can be work done in this area to make this process easier. The future of integrated previz is already here, it would be nice to have a better workflow.

     

    Cheers!

    • Love 1
  4. Should we make an enhancement request for this? It seems that this process is very labor intensive.

     

    I would think some sort of automation, and information for the user would be desirable?

     

    I know in the past I have encountered a change to an already existing fixture that has caused issues. I would think there should be a nice way to get these "release notes".

     

    Along with a way to somehow show we are out of date... vs just checking for an update... and it then getting applied without any options...

    • Like 1
  5. On 3/20/2019 at 11:27 AM, bbudzon said:

    MVR now names geometry according to the data contained in the MVR! This means that you can name objects in VW and they will come over to Vision with the proper name instead of coming over with MeshShape everywhere! If you do not provide a name, we will default to the name in the OIP. Straight Truss will come over with the name Straight Truss, Slabs will come over as Slabs, Doors will come over as Doors... you get the point! No more giant lists of MeshShapes with absolutely no idea what is what!

     

    How does this work for a simple extrude shape? where is the Name for the MVR object?

  6. On 8/29/2018 at 12:50 PM, Jim Wilson said:


    Correct, management wanted to make sure that when you were in the beta section, you knew it. It overrides the user selectable theme. Sadly I cant make it have a light and dark beta theme based on your own preference in the rest of the forum.

    Seeing that the dark theme is really nice, is there a way to create a dark "beta" theme that maybe makes the chevron theme in the background a dark red and dark theme?

     

    I totally see how it needs to stand out to remind people they are in, or not in the beta sections, but it is like turning on the sun!

     

    Cheers

  7. Is anyone else having issues where the work space windows keep re sizing? I have attached two pictures to explain what is happening. The correct picture is how I have it set, and then I go to edit workspaces, hit okay and come out and then it changes to something different.

     

    Am I not saving the space information correctly?

     

    They are staying ordered correctly but its almost as it its not keeping some of the position data for the windows on the side panel...

     

    Cheers!

    Correct.PNG

    Not Correct.PNG

  8. 33 minutes ago, Edward Joseph said:

     

    We are looking into prisms, there seems to be a bug with some prism fixtures which may be due to our control channel fix. (things like the vl4k, PRG Bad Boy, etc should be working as intended now.)

     

    Ah, yeah I am seeing it in the Sharpy as well.I presume this will just be a fix that is resolved when you run the updater?

     

    Short of not being able to move groups of things into an Xform easily it is looking really good!

     

     

×
×
  • Create New...