Jump to content
Altivec

Advanced Discussion on Efficiency

Recommended Posts

Since I see that VW coders and software designers sometimes lurk in here to help answer some questions, I wouldn’t mind some advanced discussions on how I should be doing things to make my files and work more efficient.  I like to push the limits of both software and hardware to achieve the best possible results so I spend a lot of time doing things that I think make the software more responsive and make renderings quicker.   The thing is, I have no concrete proof that I should be doing these things or if they make any difference at all. 

 

I always thought, the efficiency of textures was very important, so any time I use an image map, I go through great length to keep them as dimensionally small as possible and I painstakingly adjust compression levels and select the best image format to make sure the file size is as small as possible.   My rational for this is that if you have hundreds of textures going on in a render, it would be a lot easier on the software to load and buffer these smaller files.

 

About a year ago, I extracted an image out of a vectorworks texture and noticed it was a png file,  but I knew I imported it as a jpg file.  I brought this up to Jim and eventually  learned that Vectorworks converts all of our image maps to png regardless of what format we put in. Ever since, I have felt that I’ve been wasting my time compressing these files because vectorworks will change it anyways.   These are the types of questions I would like answered on a more factual level.

 

Here are a bunch of a questions along that line:

  • Is it more efficient to use procedural textures or image map base textures?
  • Should we be saving our image maps in PNG before importing them?
  • If we do import our image maps as PNG, does the compression settings we set stay intact or does vectorworks change them anyways?
  • Does the file size of images have any bearing on speed or performance?

 

I also have the same types of questions when it comes to modelling.  My belief is that native procedural objects are more efficient than meshes and 3D Polygons, but are they really?

  • Are procedural objects more efficient than meshes?  What I mean by procedural is; objects generated from VW tools with no conversion (an extruded polygon with fillet edges or multiple levels of add or subtract solids)
  • Does converting these objects to “Generic Solids” make things more efficient?
  • Are Sub-D objects efficient?  The heavy lined appearance of them gives me the impression that they are not, so again, I convert them to generic solids which gives the visual appearance of a not so intense object.  But maybe I’m wasting my time and removing editable for absolutely no reason at all.

 

I’m hoping someone that knows the inner workings of vectorworks could shine some light on some of these things so that we can improve the way we and the software works.

  • Like 1

Share this post


Link to post

I can answer some of these definitively but will leave the others for wiser minds:

 

Should we be saving our image maps in PNG before importing them? If we do import our image maps as PNG, does the compression settings we set stay intact or does vectorworks change them anyways?

They are internally converted to PNG anyway, so you do not need to. Resolution should be maintained after conversion within reason, however if you have multiple gigabyte humungous res images I think they may be capped but its really really high if I recall correctly.

 

Are procedural objects more efficient than meshes? 

Yes. Our handling of 3D polys (which in Vectorworks is how we handle meshes anyway) is extremely inefficient and I normally avoid them personally except for when I need very specific geometry that I can import from 3Dwarehouse or somewhere similar.

 

Does converting these objects to “Generic Solids” make things more efficient?

Yes IF the object you converted had a complex, or many levels of history or an extremely complex single level of history. For instance if you added a solid to a solid, added that to another solid, added that to another solid etc for a number of levels, that object would be much slower in all geometric calculations and large in file size because of all the history contained within it. Generic solids conversion removes that history. If the object only had one level of history and it was only two object interacting in the solid subtract for instance, you wouldn't notice much difference. If you only did one solid subtract but you subtracted 500 objects from the main one, you'd see the difference with just one level of history.

 

Are Sub-D objects efficient? 

They are effectively containers with meshes inside, so not very. I normally reserve using SubDs for organic or complex geometry that can't be made easily with the older solids tools.

  • Like 2

Share this post


Link to post
13 hours ago, Altivec said:

Does the file size of images have any bearing on speed or performance?

 

I believe it does (based on experience). Clearly the file size gets bigger but the more textures I have in the document the slower VW 'seems' to be. It seems to be the same with file size as well.

 

I generally have 2 or 3 options. With a repeat its not an issue because I have a small repeat. With a non repeat I either map it to the object using Photoshop (take an image of the object and size it in PS) or use a decal. In these cases I try to keep the image size (resulting file size) as small as possible.

 

For me the bottom line is I still try to keep everything as small as possible

 

However it does throw up another question and that is if you generate a Web VR file (not done it yet) then it seems to me all the normal rules of texturing now apply so you would be right to work hard to get the right size texture etc.

Share this post


Link to post

Some excellent information here.  Thanks Jim...  But with answers comes more questions, lol

 

20 hours ago, JimW said:

Should we be saving our image maps in PNG before importing them? If we do import our image maps as PNG, does the compression settings we set stay intact or does vectorworks change them anyways?

They are internally converted to PNG anyway, so you do not need to. Resolution should be maintained after conversion within reason, however if you have multiple gigabyte humungous res images I think they may be capped but its really really high if I recall correctly.

 

Yes.  I realize it converts our images to PNG but I think what I'm after is, what exactly is VW doing to our images?  For example.   Lets say I have a 1MB jpg image.  What I usually do is bring it into an image editor and compress it down to lets say a 100 kb jpg (Dimensions are the same, just highly compressed).  Since VW is converting it to PNG.  Is there any benefit to compressing the file size to a 100kb or is the resulting PNG file going to have the same the file size and efficiency whether I imported the original 1mb file or the 100kb file.  In other words, Did I just waste my time and made my image look worse(artifacts) by compressing it with absolutely no benefit or did reducing the file size by 10X improve this textures efficiency?

 

Same goes with PNG.   In an image editor, I have the ability to adjust many settings including limited custom pallets, 8 bit, 24 bit, resampling options.  If I spend the time using these settings to get the file size down and I import the image as a PNG. does VW keep my carefully crafted PNG  settings or does it also convert my PNG to what ever it likes.

 

20 hours ago, JimW said:

 

Are procedural objects more efficient than meshes? 

Yes. Our handling of 3D polys (which in Vectorworks is how we handle meshes anyway) is extremely inefficient and I normally avoid them personally except for when I need very specific geometry that I can import from 3Dwarehouse or somewhere similar.

 

I agree completely.  I hate 3D polys and try to avoid it if at all possible.   I was just wondering if I should be.  Its great to hear that they are inefficient so I can continue avoiding them

 

20 hours ago, JimW said:

 

Does converting these objects to “Generic Solids” make things more efficient?

Yes IF the object you converted had a complex, or many levels of history or an extremely complex single level of history. For instance if you added a solid to a solid, added that to another solid, added that to another solid etc for a number of levels, that object would be much slower in all geometric calculations and large in file size because of all the history contained within it. Generic solids conversion removes that history. If the object only had one level of history and it was only two object interacting in the solid subtract for instance, you wouldn't notice much difference. If you only did one solid subtract but you subtracted 500 objects from the main one, you'd see the difference with just one level of history.

 

That's great to know.   This helps out a lot.  So when making my symbols I will have to make two of them.   One that is the original editable one and one that's a generic solid to use in my models.   This is the exact stuff I want to learn in this thread.
 

20 hours ago, JimW said:

 

Are Sub-D objects efficient? 

They are effectively containers with meshes inside, so not very. I normally reserve using SubDs for organic or complex geometry that can't be made easily with the older solids tools.

 

Wasn't expecting that answer.   Wow.   So Sub-D are actually meshes and not procedural.  I was thinking the opposite because they look so smooth when rendered.  Yah, if these are meshes and they are that fine, I can see them bogging things down.   Their appearance, at least in wireframe mode changes when "converting to generic solid".  Do you know if this lightens the load a bit or is it still the same mesh regardless?  

Share this post


Link to post

VW stores all image textures in the VW file.

PNG is a quite ok format as it has a lossless compression. Not the most effective though.

Your image file size may be larger than your original JPEG. But at least the images wont get

worse, if someone bombs in large BMP or Tiff files.

If you get problems with RAM or file size, you can set VW to use JPEG format for your textures.

Normally just don't care about VW and image formats.

 

Another thing is that the renderer has to decompress all images again which needs some

processing time. So most pro texture libraries use uncompressed formats like Tiff or old TGA.

I use JPEG for my libraries though as texture quality isn't everything for me and I do not use

high res textures anyway.

 

 

For the VW file efficiency.

I am not sure if VW's mesh/poly render behavior is really as bad a s Jim said, I did not notice

any disadvantages in rendering or OpenGL so far. But handling these for modeling is indeed

a bit strange.

Generic Solids are the best if you can renounce of parametric history.

But it is quite ok to use all parametric Arch Objects, Extrudes, Solid Add and Subtractions and

what else VW offers for common content creation. Just avoid many unnecessary nested Solid

operations that you really don't need.

Plus, make use of Symbols for any Object that will appear in several copies

This will help of course file size, as well as load times for OpenGL or RW Rendering.

Share this post


Link to post
2 hours ago, zoomer said:

VW stores all image textures in the VW file.

PNG is a quite ok format as it has a lossless compression. Not the most effective though.

Your image file size may be larger than your original JPEG. But at least the images wont get

worse, if someone bombs in large BMP or Tiff files.

If you get problems with RAM or file size, you can set VW to use JPEG format for your textures.

Normally just don't care about VW and image formats.

 

Sorry Zoomer,  I think you are misunderstanding my question.  I am not asking if PNG is good format nor am I complaining that VW converts them to PNG.   My questions are solely to find out if there are any benefits to pre-processing images before bringing them into VW.  and if so, what is the ideal thing we should do.   Should I be compressing my images in Jpg?  Should I be optimizing a minimal palette in PNG?  Should I be importing an uncompressed Tiff?   or VW will  treat all formats the same and I would end up with the same efficiency no matter what pre processing I did.

 

 

2 hours ago, zoomer said:

 

Another thing is that the renderer has to decompress all images again which needs some

processing time. So most pro texture libraries use uncompressed formats like Tiff or old TGA.

I use JPEG for my libraries though as texture quality isn't everything for me and I do not use

high res textures anyway.

 

Now you lost me.   So you are saying that if I want high quality textures, I need to import them as Tiff.  In which VW will then convert them to compressed PNG thus losing its high quality format.  But then when rendering VW will convert the PNG back to Tiff without any loss of quality.  I don't believe thats possible.  Once the file is compressed, you can't go back without losing some quality.

 

I can understand that VW will create a better PNG if I import a tiff over a jpg and that is where my question comes in.  If there is no improvement in texture efficiency whether I import a compressed jpg or a pristine uncompressed Tiff, then I've been doing it wrong.   Instead of using compressed jpg which is give me no benefit, I should be using tiff and getting better quality with no efficiency penalty. 

 

 

2 hours ago, zoomer said:

 

 

For the VW file efficiency.

I am not sure if VW's mesh/poly render behavior is really as bad a s Jim said, I did not notice

any disadvantages in rendering or OpenGL so far. But handling these for modeling is indeed

a bit strange.

Generic Solids are the best if you can renounce of parametric history.

But it is quite ok to use all parametric Arch Objects, Extrudes, Solid Add and Subtractions and

what else VW offers for common content creation. Just avoid many unnecessary nested Solid

operations that you really don't need.

Plus, make use of Symbols for any Object that will appear in several copies

This will help of course file size, as well as load times for OpenGL or RW Rendering.

 

I don't think Jim was implying meshes are devastatingly bad.  If your models are not that complex, you probably won't notice a difference.  You should also keep edit-ability over converting objects to generic solids if that is the case.   But this topic is on efficiency.  My models are huge, 2GB+ and I have thousands and thousands of objects, with several hundred textures.   When you add up all the tiny bits of efficiency in each object and each texture, it makes a big difference in the end.

Share this post


Link to post

I meant you should not care about the image format as VW converts and stores everything

in PNG anyway. So optimizing just means using a suitable texture resolution.

Use any image format suitable for you to create your image texture collections or library.

PNG will keep the quality you put into VW.

 

A compressed format, like jpeg has to be decompressed any time it will be shown or used

in render calculations to get its pixels.

There is a trade off between longer load times for uncompressed images or computing time to

decompress compressed formats that load quicker. That is valid for other 3D Apps and your

custom texture library only, as VW will use a compressed format (png) anyway.

 

That is why I said it is important to use Symbols for copies.

Generic Solids are optimum but there is a trade off between file/render efficiency and parametric

usage for modeling and design purposes.

If you have such large projects and can't render it at the end or rotate in openGL it may be useful

to therefore convert everything down to GS Solids and have more difficult model environment but

be able to still work or render at all. If possible, I prefer the comfort of "non-efficient" parametric

options.

 

 

Edited by zoomer

Share this post


Link to post
15 hours ago, zoomer said:

I meant you should not care about the image format as VW converts and stores everything

in PNG anyway. So optimizing just means using a suitable texture resolution.

Use any image format suitable for you to create your image texture collections or library.

PNG will keep the quality you put into VW.

 

Just to clarify, a highly compressed JPG file will be uncompressed and converted to PNG. This means that you will not get any file size benefit from importing highly compressed JPGs and the quality will suffer regardless. The best approach is to prepare a PNG file at the smallest acceptable resolution and import that.

  • Like 1

Share this post


Link to post

But surely you should be trying to optimise your textures for use with Webview or VR?

 

 I would have thought that creating textures 512, 1024 etc. for this use would be essential?

Share this post


Link to post

As Matt said.

 

Or viewed from the other side, your texture library which may be used for other purposes

too (photoshop work, other software and renderers, ...) is independent from VW.

So you can save these resources in the most suitable format.

Highres and uncompressed formats if quality is important if you like.

 

When loading images into VW, make a copy with a smaller resolution if necessary when you

don't need such large resolution and keep your file fast and size small.

What ever it is, just let VW import that file and it will convert to a PNG at the end.

 

With Libraries I mean Custom Texture Image Libraries on your disk, not VW Materials

(called RW Textures) in your VW Libraries.

These RW Materials will have already converted everything to PNG.

 

Edited by zoomer

Share this post


Link to post
20 minutes ago, barkest said:

But surely you should be trying to optimise your textures for use with Webview or VR?

 

 I would have thought that creating textures 512, 1024 etc. for this use would be essential?

 

The export to webview does a separate texture conversion from the one performed on images during import from what I understand.

Share this post


Link to post
15 minutes ago, JimW said:

The export to webview does a separate texture conversion from the one performed on images during import from what I understand.

 

Thanks Jim

 

Something must happen because if I use a ridiculously large texture then that is going to really hurt a webview 

Share this post


Link to post

So from what I am gathering here texture wise.   The only important part about making an image efficient is to worry about its actual dimensions and that's it.   Compressing an image will only reduces the quality and has no actual benefit.  To give an extreme example   a 10MB tiff that is 128 x 128 pixels  would be more efficient then a 100 kb jpg that is 512 x 512 pixels.  Man, I've been doing my textures wrong for years.    This is awesome stuff and exactly what I want to learn here.  Thanks to everyone that is participating.  Please keep it coming.

Share this post


Link to post

Yes I would not worry about file formats when using images in VW.

Just use an appropriate image size depending on image importance.

(Even there I would not care as long the file and rendering handles well)

 

A true 3D artist mostly will use much larger and much more of high res textures 

than I ever will. Some may even get payed for Polygon amount and MB's

of their textures used ¬¬

My main focus is on render times, not so much on quality. I try to keep everything simple.

I come from a time where Hiddenline Renderings needed 5 hours and such things so

I am much more stingy with polygon amount (3D resolution of curved elements)

or avoid any textures (Bump, Displacement) that don't have much effect or are not

very important, anyway.

So I most times had enough reserves if things get more complicated at the end.

Share this post


Link to post
On 11/8/2016 at 5:59 AM, barkest said:

 

I believe it does (based on experience). Clearly the file size gets bigger but the more textures I have in the document the slower VW 'seems' to be. It seems to be the same with file size as well.

 

I generally have 2 or 3 options. With a repeat its not an issue because I have a small repeat. With a non repeat I either map it to the object using Photoshop (take an image of the object and size it in PS) or use a decal. In these cases I try to keep the image size (resulting file size) as small as possible.

 

For me the bottom line is I still try to keep everything as small as possible

 

However it does throw up another question and that is if you generate a Web VR file (not done it yet) then it seems to me all the normal rules of texturing now apply so you would be right to work hard to get the right size texture etc.

 

Yes - I have found in the past that if the image I use for the texture is too big - it will "fall off" after a while.  I am going to sound like a simpleton when I say this - but when my computer gets tired - it stops being able to handle the large image based textures and I have to restart.  I try and make the image based textures as small as possible before import.  

Share this post


Link to post

TIP: An old trick of mine is to select all textures in the resource browser and extract images (via contextual menu). You can then look at the sizes of those image files (on disk). Any large ones can modified in an image editor to reduce their resolution, then imported back into the texture.

  • Like 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

 

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.

×