3dsMax bitmap filtering - AXYz People BYTE hard :-)

[BrianKitts]

I'm creating an optimized library file with all of our AXYZ people. All set to vray materials, and I've converted all of the hi-res tiff files to compressed JPGs (all under 350k as opposed to the old 5MB).

 

Whenever we fill a scene with these buggers (before my new optimization) we either would have run out of memory or gotten an error about not enough filtering tables.

 

So my question is this, what is the benefit of the bitmap filtering? I know you can turn it off, so I'm considering turning the filtering off on all the people materials as I'm going through each and every one and setting them. Anyone think this would be a bad idea?...I'm assuming this may alleviate the error of running out of filter tables.

[Ricardo Eloy]

I think the problem is not actually the bitmap filtering, but the size of the bitmaps loaded. They're are literally eating up your RAM, so instead of turning the filtering off (which is what makes bitmaps look a bit better on the rendering), decreasing the JPEG size is the way to go, for it will make your object much easier to process.

[BrianKitts]

Well.... so far so good, looks like the filtering didn't make a difference. I now have axyz's professional design bundle 1 completely compiled into one file (at least the still people)

 

46 people, all vray materials, and all textures converted to JPG, took the textures folder from 330MB down to 27MB!

 

edit.... although now maybe I'll try it (after ricks comment) with the filtering back on. BTW the fuziness in the people attached is the jpg compression not the textures, looks good on my screen.

[Chad Warner]

Is this the professional bundle that has all the bip files and all that? What do you think of it?

[Matt Clementson]

Word of warning to any fR users wanting to do the same - don't! You'll get more efficient performance if you convert the textures to uncompressed TGAs as the Dynamic Bitmap pager will save you RAM doing this rather than using JPGs.

[BrianKitts]

Is this the professional bundle that has all the bip files and all that? What do you think of it?

 

Yes it is, and it's a great package....the best part being the cd when it "installs" it on your system is it lets you select your units. No more conversion headaches from all their stuff being in metric. And of course theres the metric version as well if thats what you want.

 

I use the work install loosely because it's just an interface for it to copy the appropriate files to wherever you point it at.

 

I've played with the bip's and mocap files, but not in production.... but it was simple and easy to play with.

[Chad Warner]

Good to know. We purchased some of the standalone bip files from them and they were a little bit of a hassle.

[FlyinHawaiian]

Good to know. We purchased some of the standalone bip files from them and they were a little bit of a hassle.

 

Eh? How do you mean? I'm looking into purchasing the bip files soon and am interested to know what sort of problems you've run into.

 

Thanks!

[Nic H]

Iv been using these with the included BIP files and have found them fairly easy, except when it comes to the scaling moving issue with bones which is a bit fiddly.

 

I ended up using a point cache modifier and 'baking' out sets of mesh people and pc2 files with no bones that are easy to use relocate, scale, offset animation sequence etc.

 

Also I think you would be better off reducing the pixel size of your textures rather than the megabyte size to get more textures into your scene memory wise.

 

also is turning blur to 0.01 the same as turning of filtering?

[FlyinHawaiian]

Hey thanks Nicnic. I've seen that done (pointcaching as opposed to live biped) in that past and planned to do it myself (if I can convince myself that the axyz bip files are worth picking up). The scaling issues, etc. have always been a hassle w/biped. I just wanted to be sure that the bip files were clean and usable.

 

In regards to filtering, I'm pretty sure that blur really has little to do with filtering.

 

From the Max help:

 

Filtering is a technique of antialiasing the bitmaps in mapped materials by averaging pixels. The Pyramidal and Summed Area options provide two methods of pixel averaging. Only one can be active at a time.

 

Both methods require approximately the same rendering time. Summed-area filtering generally yields superior results but requires much more memory. Pyramidal filtering requires the program to allocate memory equal to approximately 133% of the size of the bitmap. By comparison, summed-area filtering requires the program to allocate approximately 400% of the size of the bitmap.

 

Use summed-area filtering only for smaller bitmaps, and avoid using any more such bitmaps in a scene than necessary.

 

Pyramidal filtering is quite adequate for most purposes. However, because it applies filtering as a function of distance, irregular antialiasing might occur on detailed texture maps that are applied to a plane receding into the distance. The effect of pyramidal filtering on extreme perspectives such as this is even more noticeable in animations, where portions of the texture map appear to "swim." If this occurs, turn on summed-area filtering for the material.

 

Interesting to see that summed area uses 400% of the memory the regular bitmap is allocated. (And it does look a little better, but 400% better? Probably not worth it, especially if you're already tight on ram)

 

In my experience, you generally won't notice that filtering is turned off for a high-res still, but you'll definitely notice it on things like card people and trees etc in animations. It really causes flickery issues and can be very distracting.

[Chad Warner]

Eh? How do you mean? I'm looking into purchasing the bip files soon and am interested to know what sort of problems you've run into.

 

Thanks!

 

Mainly just the scaling and moving thing. The quality of the bip files was great, it was probably more of my inexperience than anything that was making trouble for me.

[Nic H]

give point cache a try, will fix that problem.

[Chad Warner]

I'll definitely do that.

[Chad Warner]

give point cache a try, will fix that problem.

 

I Just tried it, and it works great! Thanks for the tip on this.

[quizzy]

I've rendered animations with lots of axyz peeps in them and really never had memory issues. bu that isue might be vray? I dont know I dont use vray. you also find that using JPG's uses as much memory as uncompressed formats since max has to uncompress the JPG's to real uncompressed pixels anyway. For the load speed and file sizes, yes if you have limited free space on your hard drive and if you have a 100mb network maybe...

 

I'll have to take a look at that point cache as well.. found the scene becoming a bit heavy to work in with more than 60 axyz fully animated with the bip files. Also what I found lacking in the bip files I purchased from the axyz site was that there are not many variations in the movements. You only get 1 walk movement and 1 "waiting" movement.

 

So if any of you found more bip-file websites that I can use for the axyz peeps, tell me...

[Nic H]

^ Yep Id love more useful BIP files, like at least 5 walks, 5 standing/static poses etc. No weird robotic shit like the man who pulls his phone from inside his stomach!

As soon as you get large groups the movements get very same/same.

 

Have you looked into motionflow/motion mixer? Thats pretty easy to use and you can 'blend' BIPs together to make new combinations. Pretty useful once you get into it.

 

For my point cache people I always delete teh bones / helpers as well. Helps keep scenes manageable.

[RyanSpaulding]

Iv been using these with the included BIP files and have found them fairly easy, except when it comes to the scaling moving issue with bones which is a bit fiddly.

 

I ended up using a point cache modifier and 'baking' out sets of mesh people and pc2 files with no bones that are easy to use relocate, scale, offset animation sequence etc.

 

Excuse my ignorance on this...could someone explain this to me? If I understand correctly, this is a way to get say a walking BIP file into a mesh, and then applying the modifier saves this animation as vertext data without the bones? Thus making it easier to work with?

 

EDIT: NVM. Got it. How simple and nice is this?!?

Edited July 25, 2008 by RyanSpaulding

[Nic H]

yep. exactly right

try it out on one of the demo models from axyz. I think they still have a free model you can try out?

[RyanSpaulding]

Might I reiterate how much I hate trying to fit a new biped to the t-posed models? I do, I do. The structure of them never matches the biped (shoulders typically too low)...and once you adjust the biped to match the mesh, the BIP file then totally mucks up the mesh. ARRRRRG!

[Nic H]

yep normally try and get someone else to do that bit

[RyanSpaulding]

Sometimes I think I'm doing it wrong.

 

1. Open AXYZ model.

2. Delete AXYZ's bones and their Physique/Skin Modifier

3. Change units to Architectural / System Units to 1 Unit = 1"

4. Rescale the mesh to be 6 ft tall

5. Add a new biped

6. Adjust biped's pose to match pose of mesh

7. Adjust the mesh to more closely fit the bones

8. Add skin modifier, pick the bones

9. Adjust envelopes so the bones seem to control the right part of mesh

10. Load the BIP file

 

The result? GARBAGE. Sonnnnnnnnn....ovabitch.

 

I mean, would it not make sense to design your models so that a standard biped's dimensions fit the mesh? Once you mess with the biped, it'll warp the mesh and resulting mocap data.

Edited July 25, 2008 by RyanSpaulding

[Dave Buchhofer]

also the amount of ram used by a bitmap is the same regardless of which filetype it is on disk.

 

heres a paste of some info i kept, though i forgot the actual source now, it was on the vray forums at one point they're talking about the frame buffer, but its the same calc for any bitmap

 

-----------------------------------

 

you cannot render too many at too big sizes to a memory frame buffer. It's a simple calc actually. The frame buffer has to keep an uncompressed float image in memory for each element.

 

Example given:

 

You render at 4kx3k that means one RGB layer needs:

 

4000x3000x32x3 = 137mb if I didn’t fuck up unit conversion

 

so now you got 9 elements = 9x137mb = 1.2GB alone for the Renderlements.

 

To prevent that you can turn off the memory frame buffer and it will render fine. Note that you have to uncheck "Get Resolution from Max" and set the Max resolution to 1x1 pixels, otherwise max itself will still reserve memory for its own VFB.

 

Regards,

Thorsten

 

-----------------------------------

 

This same exact calculation comes into effect for each and every texture that is included in the scene. Which is why we try and keep our textures to appropriate sizes!

 

Some examples:

The basic calculation for megabytes

 

Length * Width * BitsPerChannel * NumberOfChannels = bits of ram per image

 

512 * 512 * 32 bits per channel * 4 channels (Red, Green, Blue, Alpha) = 33554432 bits = 4MB

 

1024 * 1024 * 32 * 3 channels (RGB, but no Alpha) = 12 MB

1024 * 1024 * 32 * 4 channels (RGBA) = 16 MB

 

2048 * 2048 * 32 * 3 channels (RGB, but no Alpha) = 48 MB

2048 * 2048 * 32 * 4 channels (RGBA) = 64 MB

 

4096 * 4096 * 32 * 3 channels (RGB, but no Alpha) = 192 MB

4096 * 4096 * 32 * 4 channels (RGBA) = 256 MB

 

Conversions provided by : http://www.matisse.net/bitcalc/?input_units=bits&notation=legacy

 

THAT’S JUST THE RAM TAKEN UP BY A SINGLE TEXTURE OF THAT SIZE. 1x4096 textures takes up 256mb of ram! Image size on disk has no effect on how much ram is taken up by the texture, it is only the pixel dimensions that define RAM usage.

 

The final frame buffer that you view the image in, counts as a texture in terms of how much ram it uses! That’s why the new Vray thing where you can save the image directly to disk without sending it to the screen is such a godsend for huge renders.

 

[ni4417013@hotmail.com]

I have 1 link for your problem but I can't post it T_T