Jump to content
Sign in to follow this  
PVA - Jim

Vectorworks 2015 , 64bit and other technical questions

Recommended Posts

Although I am working on one specific file, I quickly tried it out on some older files and got the same problem. I am going to look into it further and see if I can isolate it in any way. I wanted to start here in case this was a known issue. The other reason is because I've never even seen the first progression bar "Textures" before, I always got "Geometry" first, followed by "Indirect Lighting" and then "Render".

Share this post


Link to post

Is the Resource Browser open?

Is it set to display thumbnails?

One trick that seems to improve things it is to purge unused textures and close the RB.

Share this post


Link to post

Yes, I always keep my resource browser open and set to thumbnails. I tried your suggestion of closing it and it did not make a difference. Thanks for the idea though.

Upon further investigation, its definitely linked to the initial "Textures" stage where I am assuming its loading textures. The rest of the stages; geometry, indirect lighting, and rendering are going at its usual speed. The problem is the loading texture stage takes 10 to 15 minutes no matter what quality or dpi the render is set at and the actual rendering only takes a few minutes. I wish there was more info in the textures progression bar to see if its getting stuck on a specific texture. The progress bar is not jumping and appears to move at a slow but steady progression.

I am going to try deleting textures one by one to see if I can pin point a texture, but again everything in this file was working fine prior to me upgrading to yosemite and SP1 and I am have the same problems in other files that were working fine too.

Share this post


Link to post

I don't think you have PDf data as textures or 2 GB HDRI images.

So not really related to your problem.

In general, Textures load faster as TIF than as JPEG or GIF as the

renderer has to decompress these each time.

(I learned this years after I converted all of my textures to JPEG

for file size reasons :) )

BTW the file worked well in 2014 and older OS X ?

Would it still work in 2014 with OS X 10.10 ?

Share this post


Link to post

What... we can't have 2GB PDF Textures... Just kidding. I am very anal about my textures and try to keep all image maps under 100K. This particular file does have over a hundred textures though.

I did not know TIF was faster than JPEG. I just thought the smaller the file size, the faster the load and render speeds would be. I usually set my compression at around 40% for jpegs and make sure my images are no greater than 500 pixels square. This usually gets me below the 100k mark. I'm sure these same sized images would be greater than 1mb if they were uncompressed tif's. Jim, can you confirm that Tif's are the way to go to increase render speeds? Your confirmation would definitely change the way I do things as I don't care about file size, its all about speed to me.

The file did work fine in 2014 and OS X 10.9, however, I added a lot to it while using 2015 and OS X 10.9 with no problems. I just tried exporting the file down to 2014 and I get the same "Texture" problem running in 2014 under OS X 10.10. Thanks for getting me to try this out because this now eliminates VW2015 as being the problem.

I also tried deleting about 20 textures at a time and each time it proportionately got quicker so I can't isolate it to just one texture. Once all the textures were gone, the texture progress bar was super fast but my renderings look kind a white. LOL This is just weird... I have been using many of these textures for years and have never had a problem. Since nobody else seems to be experiencing this, there has got to be something wrong with my specific set up. I will try bringing a few files home with me tonight and try them on my home computer.

Share this post


Link to post

I Just found out something interesting.

I thought the easiest way to see if I have a stray large image or something was to select all my textures and use the "Extract Images" command and put them all in one folder and sort that by size. The strange result I got was that every single image was a PNG file. PNG is not what I used to create the textures so I'm not sure what has happened there. When I use to use the the "Extract Images" command, I would get the exact same format that I inputed. Can anybody else confirm this.

I am wondering if this has anything to do with my slowdown considering that these PNG files ballooned the file sizes.

Share this post


Link to post

Sorry for getting all posty but I must correct something I said in my last post. Apparently, it is documented that the "Extract Images" command does export the images in the PNG format and this isn't something new to 2015.

After all these years, this is a totally unexpected process to me. Why does VW do this? When is the conversion to PNG taking place? Aren't the images being stored and rendered in their original format? If so, why doesn't VW just extract the original image instead of converting it to PNG during the "Extract Image" process?If all the textures are being converted and stored as PNG during texture creation, shouldn't we be creating our texture images as PNG's to begin with so that we can control our own conversion and file sizes? I don't understand the logic behind any of this.

Share this post


Link to post

Your work on this is VERY informative, and the questions are good. So "posty" is good.

I hope Jim W and others can add comment and answers.

-B

Share this post


Link to post

Funny,

hadn't noticed this. Found an export - indeed.

If the delivered VW textures are stored in that format ok.

But for custom textures f.e. Jpeg or Tiff I don't think that

is a good idea.

Share this post


Link to post

I have always used PNG for my textures out of habit, I never noticed extracting always gave you PNG even if the source was another format, I'll ask about it.

Altivec:

In the meantime, send me one of those textureful files that you're seeing the delay in, I can test it here with a number of versions to see where the delay started. A link to it is fine if the file is too large to email, or just let me know at tech@vectorworks.net and I can send you an upload link, reference this thread in your email please.

Share this post


Link to post

Unfortunately, I was not able to try it out on my home computer last night but I did some more testing today.

I was no longer confident in the export down to 2014 results because I wasn’t sure if 2015 changed my textures and included these changes in the 2014 file. So I found an old 2014 back-up of this file that was never upgrade to 2015 and launched it in 2014. The problem exists there too and it never existed there before. So I booted up in OS X 10.6.8 which I have on another partition and launched this same file in the same VW2014 and the textures loaded in seconds. I was not able to try VW 2015 in 10.6.8 because it has a big can’t open symbol on the application.

So In summary:

OSX 10.10.1 + VW2015 = Bad

OSX 10.10.1 + VW2014 = Bad

OSX 10.6.8 + VW2014 = Good

So I guess the last thing to try is to see if I have this same problem on another computer running Yosemite. Jim, I will try that at home and based on those results I will send you the file.

Share this post


Link to post

Jim:

As my slow loading texture problem may or may not have anything to do with the PNG conversion thing, I am very interested in finding out more about the best image format for creating textures regardless of this issue.

I am curious why you always used PNG's as your image type of choice? PNG is basically a glorified GIF replacement and used as a portable internet image format and not intended for professional quality graphics. It has its place like for BMP maps and such, but JPEG will give you better file size/quality and if you are going strictly for quality TIFF is the best proffesional format. This is why I am puzzled by all of this.

Share this post


Link to post

Just habit mainly, I work with a lot of varying applications and PNG happened to be a common supported format. all the stuff I made had to be small and compact so it worked better than JPG at the time. I never picked it based on its performance in Vectorworks explicitly.

Share this post


Link to post

JPG is best for image files with large variation in detail and color

like Photos and grass textures etc.

PNG like GIF is best for vector graphics, like texts or technical drawings

with marginal color variation. And I think it supports an alpha channel.

Both have comression loss.

BMP and TIFF are kind of raw data.

TIFF can be compressed (f.e. LZW) but it is lossless, similar to ZIP.

Share this post


Link to post

Thanks zoomer

That is a very good description of where to use the various formats. Besides the conversion of vector to bitmapped graphics, I use PNG for anything that has a very small palette of colours or any black and white images that will be used as image masks.

Now we just need to verify if Vectorworks actually use the images in the format we import them in or if they all get converted to PNG. Jim: I hope you are still asking this question to the renderworks gods. That question, with the follow up question of Why? and if the answer is no, Why does it get converted to a PNG when we extract the images?

If it does convert it to PNG's, it is a big no no for us to compress an image into JPEG only to have it recompressed as a PNG and I would definitely alter the way I make my textures.

Share this post


Link to post

I'll get an official answer, just waiting on a quick meeting.

However, from what I know of how Vectorworks handles images, it is entirely possible that we convert all imported images into either JPEG or PNG automatically (when you import any image file, this is seen directly by the user) even though an imported image says it is a "Bitmap" when selected.

The same image import system is used when creating an image based texture, so its very likely that we auto convert images into PNG when they become textures and thats why when we extract the image back out, we get a PNG.

I'll post once I know the real answer for sure, however.

Share this post


Link to post

Awesome thanks.

If you are having a meeting and it does end up working the way you described it. Can you ask them if there is still some sort of conversion/compression applied if we import our images as PNG's to begin with. In other words, If I spend time tweaking the quality and size of my PNG is it just a waste of time because it will just get recompressed anyway.

Share this post


Link to post

I finally had a chance to bring some files home and try things out. I installed a fresh copy of vectorworks 2015 and tried it on OS X 10.10 and I had no texture loading problems. I added SP1 to see if the problem was introduced there and again I had no problems.

So I guess my problem is specific to my work computer. Since it happens on both vw2015 and vw2014, I have to conclude it has got to do something with my yosemite install. Its just strange because I have no other issues. Everything else in vectorworks runs fast, and all my other applications work great too. I guess I will have to live with it and hope it corrects itself in the future.

Share this post


Link to post

A quickish test, create a new Administrator user account on the affected machine via these steps:

http://kbase.vectorworks.net/questions/805/Creating+a+New+User+Account+%28Mac+OS+X%29

Then, log into the new account, launch Vectorworks (it may ask for your SN, have that handy) and then try the renderings again. Let me know the results.

Share this post


Link to post

FYI - The links on the page you sent me to do not work but I assume you just wanted me to make a fresh OS X admin user account in which I knew how to do.

Yes, I had to re-enter and activate vectorworks. Hopefully the activation guys don't get suspicious on me as I'm activating a lot of copies here. The pref file was obviously new because all palettes and windows were in different locations. Unfortunately, the problem still existed in this new user account.

Share this post


Link to post

Gotcha, and no the activations don't count as new ones, you could activate it on 80 user accounts on the same machine and they still only count as one, it tracks hardware and network info to avoid that issue.

Share this post


Link to post
Thanks michaelk,

I kept checking in service select under the downloads/vectorworks viewer. It only goes up to 2014 in there. Maybe Jim could advise them to add the link.

Fixed.

Share this post


Link to post
Awesome thanks.

If you are having a meeting and it does end up working the way you described it. Can you ask them if there is still some sort of conversion/compression applied if we import our images as PNG's to begin with. In other words, If I spend time tweaking the quality and size of my PNG is it just a waste of time because it will just get recompressed anyway.

Sorry for the delay, wanted to get an answer straight from the rendering manager:

JPEGs used as the source for a texture should remain JPEG and extract as JPEG. All other image formats will be converted to PNG during the texture creation (actually, converted when any image is imported at all, even if it isn't being used to make a texture) and will extract as PNG after the fact.

There is always some conversion, but there should not be a reduction in quality that you can see in a rendering, it does not attempt to compress them significantly for instance.

Share this post


Link to post

JPEGs used as the source for a texture should remain JPEG and extract as JPEG. All other image formats will be converted to PNG during the texture creation (actually, converted when any image is imported at all, even if it isn't being used to make a texture) and will extract as PNG after the fact.

Unless my machine is really messed up or something, this does not happen for me. I just created a new blank document, right click "new renderworks texture" in the resource browser, import a 126kb jpeg image into "color", close the texture and then "extract image(s)" and I get a 1Mb PNG. That is almost a 10X expansion in size.

There is always some conversion, but there should not be a reduction in quality that you can see in a rendering, it does not attempt to compress them significantly for instance.

I am more looking at it from the other side. I am willing to give up a little quality to gain speed. So if I spend all this time tweaking my image to get it to 128kb only to have vectorworks change it to 1MB I just wasted a lot of time and accomplish nothing.

So what I am gathering from all of this and please correct me if I'm wrong, is that 1) there is no way for the user to optimize or control their graphics. 2) We should be importing the highest quality image because vectorworks will do its thing no matter what we throw in there.

Share this post


Link to post

I am more looking at it from the other side. I am willing to give up a little quality to gain speed. So if I spend all this time tweaking my image to get it to 128kb only to have vectorworks change it to 1MB I just wasted a lot of time and accomplish nothing.

So what I am gathering from all of this and please correct me if I'm wrong, is that 1) there is no way for the user to optimize or control their graphics. 2) We should be importing the highest quality image because vectorworks will do its thing no matter what we throw in there.

1) Not in the granular way you are attempting to do, no. While uploading a lossy compressed image will always be worse than a high quality one, trying to get size down in the initial image file through various compression/color changes will not normally be worth the effort.

2) Yes. However this is subject to diminishing returns. Trying to load something like RAW into a texture will result in a huge resource with no visible difference.

Theres no quick scientific answer to what exactly should be done, as it all depends what the final product will be and what size/types of renderings you're working with. For instance if the final render is openGL, then you wouldn't notice much difference in anything BUT size of the final file no matter what you did.

Normally, quality should be tested in-file in the environment you're going to be rendering in, then quality can be reduced or increased to taste to balance file size and appearance.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...