How do you calculate render costs for your quotations?

[Art48]

I'm currently looking for a way to better estimate render costs or rather actual render time of a project in the offer phase.
When calculating, we do estimate how much we data prep, how much time for shading, how much for lighting, post etc. And also how many hours the project will render and then we multiply that number of hours with a fixed price per hour of rendertime to estimate actual rendering costs.

But since VRay is constantly changing, getting faster etc. pretty much the only way I could reliably estimate render costs is by taking values from experience and somehow get that in relation to current hardware, VRay versions etc.

Is there any smarter way of doing this besides having some kind of huge excel list with all the projects, rendertimes, hardware, software versions, etc. and then looking at it at a similar project in the past and try to eyeball it? How do you guys do this?
We render at our facility aswell as Rebus Farm fro bigger images. We render only stills for print, no animations of any kind.

[flino2004]

I'm very primitive and lazy for doing those calculations so I charge flat fees so old clients don't have to call me or asking for quotes....I don't do animations...I did it a couple times and was a nightmare so for the time and what I can get for them it doesn't make sense to me.
but I do charge as well a flat fee for changes.. 90% of the time works for me because depends on me to get a high rate per hour, on the other hand, the other 10% is OK and most of the time is my fault because even if the client like them and I feel that is not that good I always re-render them again.

[glorybound]

I charge a per diem, although I don't tell my client that. How much do I need to make a day and multiply it by how many days it'll take me? The better I get, the faster I can work, and the more I can charge; my daily rate goes up. I get 90% of the projects I quote, so I might be raising my daily rate because I have too much work, which is a good sign that you can charge more. If I started only getting 1/2 the projects I quote I am probably charing too much.

[Art48]

glorybound
Well we usually render really large images 10k and beyond, so we can't really not charge for render time or stick it into another position.

flino2004
Not sure what to make of your post to be honest ^^

Anyways - is noone around here calculating rendering costs?

[flino2004]

I would rate a 10k base on your experience in time for a complex scene and I would use it as a factor for over 10k. My clients don't need 10k and they have the same types of projects so to me is easy to use flat fees and render times are very predictable so they are absorbed by my fee.
of course, we have different types of clients and in my experience, they don't want a variable number. In architecture, everybody charges a flat fee or a percentage which is a flat fee as well in some way.They expect the same for consultants. (at least in my network)

[mitviz]

have a daily rate, then estimate how many days you will need and if your going to render large res just check with a render farm how long for a image that size and add it in

[Art48]

Okay all in all I get the sense that noone here puts estimated render times on their quotations, am I right? Seems strange to me. If you render large images of complex scenery render costs can easily go into the hundreds of EUR. This is a position I cannot just ignore and present the client with the number at the end of the project.

[flino2004]

Everything depends on how much the output represents for you of the whole project.... if you charge 2-3k per view or $500 the render time is going to cost you the same.....If I could do it in-house but I'm super busy I don't mind paying for a farm and is part of the fee.
I get your point but for most of the people calculating render time is very difficult... I quote for 4k to 6k in my flat fees if the client wants 10k I just let him know before starting the project that part is out of his pocket. I get the invoice they pay me back.