> For technical reasons, there is not one “absolute” figure for the average tariffs on EU-US trade, as this calculation can be done in a variety of ways which produce quite varied results. Nevertheless, considering the actual trade in goods between the EU and US, in practice the average tariff rate on both sides is approximately 1%. In 2023, the US collected approximately €7 billion of tariffs on EU exports, and the EU collected approximately €3 billion on US exports.
Blender 2.5 has changed the UI significantly from the original commercial version, and most comments I read about it say that it has improved significantly. Blender the open source project has changed and grown so much bigger than Blender the commercial product that they are totally different.
Regarding hotkeys, there were some major changes for 2.5 along with other UI changes, but after that the default have barely changed, just additions and minor changes when the underlying features change.
Making hotkeys remappable was in no way a solution to that "problem", it's a standard feature in other 3D software that a lot of users requested, especially those who wanted to make the hotkeys compatible with Maya and 3ds Max.
The mouse focus issue is more related to missing APIs. If you call operators (tools) from Python they do indeed depend on context, just like they would if you use them from a toolbar, menu or shortcut key. These are not intended to be used for scripting really, but they are available and sometimes the only way to do things because there is no equivalent API function available.
Probably yes. A really nice feature is that you can hover over a button and see the name of that Python function. Then it's hard to know if you're supposed to do it that way or not when scripting.
Another gripe I remember is that angles in the UI are specified in degrees and in Python they are specified in radians.
Yes, a big problem is indeed API documentation and making it easier to follow best practices.
Regarding angles, users want to see degrees in the UI, but the python functions like math.sin and math.cos and basically any other graphics code you find uses radians. Whatever solution is chosen is always going to make someone unhappy.
Just one nitpick, Arnold supports the same BSSRDF profiles and has been used for realistic skin rendering in movies. The gaussian profile is actually suitable for rendering realistic skin, by using a combination of multiple gaussians you can very accurately match measured human skin profiles.
Yeah, such profiles can certainly be used for skin rendering. I know that SPI used the method you mentioned on a few movies. There will be visible flaws though. The skin and especially the lips will look too waxy when using gaussians or bicubics. Weta Digital used Quantized Diffusion on Promotheus for this reason [1]. Pixar has an upcoming talk on a simple, yet highly accurate BSSRDF profile this SIGGRAPH, so let's hope the folks at Blender will implement that in Cycles.
Forward path tracing is what is used to render more than 95% of graphics you see in movies today. It's not great for closed spaces and VCM is better, but it's definitely possible to render everything with forward path tracing. People have been doing it for years, bidirectional methods have only started to get used in production very recently.
Forward path tracing with direct lighting only has been done for 'years' (about 4-5 years). Pure forward path tracing without caching of secondary illumination is being done now, but at great expense of render time and artist time to deal with the inevitable noise.
It is something that people are getting to work in the end but it is a consistently painful disaster.
So basically forward path tracing is not adequate. That doesn't mean it can't be forced to work through huge render farms, hacks, compositor painting and who knows what else.
I agree it's possible to do better than forward path tracing, but a big part of why nearly everyone switched to it was that it significantly reduces artist time, is a lot less painful and requires fewer hacks than the methods used before it.
The state of the art keeps improving but I've never heard any call the switch to forward path tracing a painful disaster, quite the opposite.
Few hacks yes, less painful I have to disagree with. It is the present and of course the future, but what I have seen is that the hacks shift to do anything possible to reduce noise, and the artist's time shifts to doing whatever they can do deal with noise. It never ends up being 'fire and forget' because renders end up either overkill on cpu time or with noise somewhere in the image.
Forward raytracing as it currently stands is awful to use at the moment on a large scale for final motioned blurred images that can be sold to a client, but because it is simpler it is still better than alternatives. That is because getting the same results out of (REYES) renderman was something left to a handful of gurus and fanatics.
Now we have a state where renders take 8 hours per frame per character per pass but people still like it better. So be it, but that is still very painful.
For a fair comparison we should compare PRMan's RIS with Cycles though, not REYES. RIS is what Pixar are focusing on and rendering their movies with now.
Yes, REYES is great at subpixel shading, rendering fast motion blur, using brickmaps with indirect light, and using very little memory for detailed displacement. But with RIS all those things are gone. PRMan's implementation might still be more efficient, I don't know, but with the switch to path tracing they are definitely giving up various advantages that REYES had.
Exactly, with the move to RIS, they're in pure path-tracing now, and they're still behind Arnold generally from a performance perspective.
Displacement and subd performance is still very impressive (compared to Arnold), but motion blur (especially deformation for curves and triangles) has a noticeable overhead now.
I think this misses the point, if someone doesn't understand open source etiquette then I would give them a friendly reply. Even if it was mentioned somewhere in the documentation, I understand that people can miss it.
It's just that if someone speaks to me in that tone, regardless if this is an open source project or if I'm working customer service for a product, I'll still think they're acting like an ass. It's not a huge deal, people act like asses all the time, but why not just raise the issue in a friendly manner?
This is the same strategy I've used in open source projects. Handling the report is annoying, but then having to go spend time fixing the issue to help someone who is being an ass is soul draining. And it only encourages them and other people to be an ass to get what they want.
So I call them out and close or delete the issue, and if they get frustrated because of that, great! This doesn't mean I won't fix the issue eventually, just on my own terms without giving that person the satisfaction. Makes me feel a lot better.
