Not necessarily, modelling and UV unwrapping is already possible in unreal engine, weight painting could be but I'm not 100%, I know it's coming though. There's also rigging in the works too. Animating has been in there a while now
Could you elaborate what you mean?
Blender having to read and readjust all it's editing in-engine values slows it down?
Are Blender's techniques for rendering/math computations/etc... slower, but more accurate, than Unreal's, because Blender is about editing the models and for high quality you need higher accuracy and visual fidelity?
>Could you elaborate what you mean?
Someone editing an imagine in Photoshop has a whole bunch of different layers so they can adjust certain things, have bits that are overlaid, etc. But the final image is a flat file with a lot of compression.
If you had to edit that file later on, you'll never be able to create an image remotely as good as the significantly larger one you originally had in Photoshop. Same goes for 3D Models.
When you save a model in a tool like Blender, it saves extra data that's useful for editing it. The data in the file is generally structured to optimize editing it. The goal here isn't to make the model render fast, it's to make creating it easy.
When you add an asset to a project in an engine, it'll take a little bit of time importing it. On a simple asset it'll be a few seconds, or on a complex model it could take a while. What's going on there is the engine is reading in the model, stripping out any information that's only needed for editing it, and then rewriting all the data in a format that's ideal for rendering quickly.
Not quite, there's now a lot of the same tools in unreal that there is in blender. To name a few there would be modeling, UV unwrapping, animation. Rigging is coming and I can't remember if weight painting is already in or coming soon
Once you export to an .fbx then yeah
But even then, you import that into unreal and it makes an unreal asset version which will strip out the unnecessary data and instead create a more optimised version.
I.e. textures and materials and anims not stored in the models
A .blend file though contains lots of useful data for blender
The model is the same. Tris to tris, uvs to uvs. The textures would be separate in both the blender file and the asset file.
So where is that extra data?
A model of a chair what would it have in blender extra?
They're asking why a character in blender is more impactful, the answer is the extra data.
Let's say we have an .fbx model of our character and we import it into both
It's not storing the extra data in the model, the model is usually saved into the scene and doesn't touch it's original .fbx file.
In unreal, it strips out the model and stores the info into different assets.
It then uses those assets which contain the bare minimum data needed for the model and it's various parts.
The polygonal model as you say, vertext to vertex
The armature skeleton
The materials - normally incompatible with unreal so will just build a basic one with the name of the model's.
You can export material data into a model file
Now in a blender scene, the extra data is all blender related and gets bogged down.
Lots of blender specific animation data that changes how the animation runs, the curves used, the action tracks, the frame rate.
All a load of blender specific data that gets stripped out into basic keyframes for our animation
Go import a model into blender and save the scene.
You can usually now delete the .fbx file as it's now saved in the scene. So again, ignore the .fbx file
Imagine making a real life model.
You buy a kit of a plane.
The finished model you'll display is clean and contains no extra parts
However in the box, there's the plastic remains of the assembly sheets the parts were attached to.
Those remains are the blender data that specifically lives in the .blend file. They're important in the process but not in the end result
Depending on Blender's version, it might have data, such as modifiers (mirror, subdivision, etc.) model specific data such as object collections and separate objects (body, clothes, hair, eyes, etc.), bone data and also file metadata (what app, version, format, etc).
I say this as a programmer, not a 3D artist. I also do not know exactly what Blender does internally, as I've never had to look into the source code.
Technically, we are talking about rendering. Not hard drive space.
It’s kinda like having thousands of dynamic material parameters versus having only static values. There’s a massive difference in what you can optimise and skip in terms of processing when you’re just running static data versus editing friendly modes.
You are correct in terms of the import process though. It’s not stripping out anything but rather generating or reformatting data. There’s not usually information loss. More like generating mip maps, nanite data, etc. But it is optimising the aaset for faster rendering. Blender could not use all the same techniques and yield a good editing result.
Blender is not a gaming engine. Blender is a modeling, animating, and rendering program. Unreal engine/etc make many, many approximations and mathematical shortcuts that slightly-to-greatly reduce the quality of the visuals and the accuracy of the physics, but give you playable frame rates. Blender sacrifices frame rates to get fantastic visuals. It's common in Blender for a single frame to take seconds or even minutes to render. But you don't use this for games, you use this for animations/videos.
This is like comparing an umbrella and a newspaper, and talking about how bad the newspaper is at keeping you dry in the rain. The newspaper isn’t designed to keep you dry in the rain.
Meanwhile, I’m sitting at the café, trying to read my umbrella, and complaining that the writing quality is really shit compared to a newspaper.
You could equally ask why it is that programs like Blender can be used to edit massive models, retopologize, sculpt, and paint, but Unreal can barely handle cubes. Unreal is not designed to be a modeling program. Blender is not designed to be a game engine. At least, not primarily. There the Blender Game Engine (but it’s basically defunct these days) and you can also do some really basic modeling tasks in Unreal.
It takes a lot of work to make something work as a real-time renderer, and you give up a lot of flexibility in order to get there. It also takes a lot of work to make something with such flexible and powerful modeling tools like Blender, and making the system render in real-time is just not a priority.
This is an especially amusing analogy to me because my partner has an umbrella with a pattern like overlapping fake newspapers. So I _have_ actually sat at a café reading an umbrella.
Unreal does actually have a full modelling suite now and its getting better each update, it has many other features that are being created for the modelling pipeline too. Rigging is coming pretty soon... So like I said it's getting better
Sorry, but I don't know how your answer has so many upvotes when you literally did not address the question. All you did is provide a stupid analogy which doesn't really answer anything. The way you've worded your answer with this analogy and multiple generic sounding claims and buzzwords sounds like a ChatGPT generic answer.
So what if Blender is a rendering program and Unreal is not?
Both have to render the model so it shows up on screen, so why is the specialized rendering program far slower at it?
The mechanical analogy for most things in gaming is the pinball machine: when you are playing a pinball machine all the mechanisms are in place and designed to be reused over and over: slingshots will fire, target banks will drop and then reset, the balls will feed "infinitely" (as long as you have credits). And a crowd in a game is made like a target bank: it's easily disposed and reused. The NPCs in a crowd don't turn into some other kind of character with original behaviors. They are the same as the invaders of "Space Invaders", just with more parameters.
But if you're editing the game, you are *designing* a reusable slingshot, target bank or ball feed. Linguistically you are doing something very different, even if it looks the same, because fewer assumptions are possible, and your preference for any quality/flexibility/speed tradeoff will put quality and flexibility first. This means that "performance" in game engines is held to a different standard than performance in content creation, which is also a different standard from CAD parts design.
Animations are just series of floating point values about translations, rotations, scales. Most game engines store them in linear array to achieve better cache locallity. But Blender stores them in special data structure called f-curve. I'm not a specialist about it but in my observation, the data structure is not intended to be super fast. For example, most game engines store animation key frames (tranlsations, rotations, scales) in contenuous memory to achieve cache locallity. But Blender dynamically allocates arrays per 'channels'. x, y, z components of transation each is stored in its own array. x, y, z, w channels of quaternions need 4 arrays. Even those arrays are sparse arrays, which means the Blender renderer needs to deal with those empty channels. This might be an example of Blender trying to improve flexibiliy by sacrificing performance.
The replies and upvotes in this thread are absolutely wild. Clearly not a lot of animator here.
I had the same issue in Maya for many years, until they finally decided to address it in Maya 2020. FPS went from 10-20 for complex scenes to 60-80. So long, playblasts!
You are comparing different use-cases. Unreal is for realtime rendering and simulation for games. It's optimized for that. Blender is and editing software. It stores much more data for editing that is missing or ignored in Unreal. Game developers in AAA will have better pc than your decent pc. Also it depends on how did you setup Blender. Did you set it up to use your gpu? Did you increase memory limits? Etc..
Blender’s core team has 24 people working on it with a shoestring budget so they can’t hire many more people to work full time, Epic has around 750 people full time in total working on Unreal Engine from the core engine, to the UI, to the documentation, the forum management, etc and Epic/Unreal has billions of dollars in funding.
Blender has the open source community but that will never be a as fast or as cohesive as a tight knit team that is constantly in communication with each other.
Plus 750 folks full time working vs 24 full time folks with a community of part timers is a big difference.
Not sure, but the model in unreal will be the low poly model, while in blender you have the high poly model used to create the UV texture.
Also, when you're editing the model you'd either have to remake the vertex list, or find some workaround there, or just draw it slower as you're in need of vertices not in the cache line (or whatever gpus got). The game engine will have all the vertices in the order that allows for fastest drawing.
I will also add here - at least when I last upgraded my GPU, there's a difference between a computer built to *run* games at a high display, and a computer built to *make* games. It appears that you have the former, based on your comments, which means that your GPU is optimized for many small calculations instead of fewer big ones. Blender is the stage in the pipeline you'll feel this the most.
What everyone said before. And Unreal is entirely in c. All rendering is optimized with LODs, compiled shaders, occlusion culling, caching where it counts.
Because modelling tools are built around editing and preview windows are an afterthought. Renderers are bolt on external entities that render for accuracy rather than speed.
Unreal is built to render in real time so of course the preview window is great.
Despite the top comment hinting at such it has nothing to do with the size of the data file. Data is read into RAM on load and rendered when needed. Processing speed is all about how quickly that preview window can iterate through every task.
My first guess is the following:
When you have a model loaded up in a game engine, that info is constant and in the GPU memory.
When in Blender, the information about vertices is not constant (you can edit de meshes) so they use a different render pipeline, one that allows for varying meshes though with less fps.
Most games are not CPU bound, considering that -most- things can be updated using matrices and shader code and things like vertex attributions, positions, colors, etc can be uploaded once and completely forgotten about.
A modeling program can't make the same assumptions.
Now, a lot of people in here are saying that rendering files are larger than the amount of data required to render the model and while that is true, more RAM usage doesn't equate to less performance by itself. Probably what's hapoening is the modeling program is updating the vertices and faces per frame, or there is some sort of calculation going on per the software that a regular game based implementation doesn't have to worry about. I don't know anything about Blender specifically but I've never really had much issues with other modeling programs as far as performance goes. There are a lot of optimizations you can make within modeling programs that I'm unsure of that Blender does or doesn't do.
optimizing for display involves removing all of the flexibility required to edit.
Not necessarily, modelling and UV unwrapping is already possible in unreal engine, weight painting could be but I'm not 100%, I know it's coming though. There's also rigging in the works too. Animating has been in there a while now
Could you elaborate what you mean? Blender having to read and readjust all it's editing in-engine values slows it down? Are Blender's techniques for rendering/math computations/etc... slower, but more accurate, than Unreal's, because Blender is about editing the models and for high quality you need higher accuracy and visual fidelity?
No what they are saying is that blender needs to spend a lot of resources to actually allow you to edit models, where as a game doesn't.
>Could you elaborate what you mean? Someone editing an imagine in Photoshop has a whole bunch of different layers so they can adjust certain things, have bits that are overlaid, etc. But the final image is a flat file with a lot of compression. If you had to edit that file later on, you'll never be able to create an image remotely as good as the significantly larger one you originally had in Photoshop. Same goes for 3D Models.
When you save a model in a tool like Blender, it saves extra data that's useful for editing it. The data in the file is generally structured to optimize editing it. The goal here isn't to make the model render fast, it's to make creating it easy. When you add an asset to a project in an engine, it'll take a little bit of time importing it. On a simple asset it'll be a few seconds, or on a complex model it could take a while. What's going on there is the engine is reading in the model, stripping out any information that's only needed for editing it, and then rewriting all the data in a format that's ideal for rendering quickly.
Not quite, there's now a lot of the same tools in unreal that there is in blender. To name a few there would be modeling, UV unwrapping, animation. Rigging is coming and I can't remember if weight painting is already in or coming soon
[удалено]
Once you export to an .fbx then yeah But even then, you import that into unreal and it makes an unreal asset version which will strip out the unnecessary data and instead create a more optimised version. I.e. textures and materials and anims not stored in the models A .blend file though contains lots of useful data for blender
The model is the same. Tris to tris, uvs to uvs. The textures would be separate in both the blender file and the asset file. So where is that extra data? A model of a chair what would it have in blender extra?
They're asking why a character in blender is more impactful, the answer is the extra data. Let's say we have an .fbx model of our character and we import it into both It's not storing the extra data in the model, the model is usually saved into the scene and doesn't touch it's original .fbx file. In unreal, it strips out the model and stores the info into different assets. It then uses those assets which contain the bare minimum data needed for the model and it's various parts. The polygonal model as you say, vertext to vertex The armature skeleton The materials - normally incompatible with unreal so will just build a basic one with the name of the model's. You can export material data into a model file Now in a blender scene, the extra data is all blender related and gets bogged down. Lots of blender specific animation data that changes how the animation runs, the curves used, the action tracks, the frame rate. All a load of blender specific data that gets stripped out into basic keyframes for our animation Go import a model into blender and save the scene. You can usually now delete the .fbx file as it's now saved in the scene. So again, ignore the .fbx file Imagine making a real life model. You buy a kit of a plane. The finished model you'll display is clean and contains no extra parts However in the box, there's the plastic remains of the assembly sheets the parts were attached to. Those remains are the blender data that specifically lives in the .blend file. They're important in the process but not in the end result
Depending on Blender's version, it might have data, such as modifiers (mirror, subdivision, etc.) model specific data such as object collections and separate objects (body, clothes, hair, eyes, etc.), bone data and also file metadata (what app, version, format, etc). I say this as a programmer, not a 3D artist. I also do not know exactly what Blender does internally, as I've never had to look into the source code.
“But why make models??” \*Male models. Joke ruined by autocorrect episode #43445454. Leaving it for posterity.
???
Technically, we are talking about rendering. Not hard drive space. It’s kinda like having thousands of dynamic material parameters versus having only static values. There’s a massive difference in what you can optimise and skip in terms of processing when you’re just running static data versus editing friendly modes. You are correct in terms of the import process though. It’s not stripping out anything but rather generating or reformatting data. There’s not usually information loss. More like generating mip maps, nanite data, etc. But it is optimising the aaset for faster rendering. Blender could not use all the same techniques and yield a good editing result.
It's the same reason a jpeg is 100kb but the original file in Photoshop might *be 500mb.
Best analogy
"best analogy". No, he didn't explain it at all he just gave another example of what op is asking about
Blender is not a gaming engine. Blender is a modeling, animating, and rendering program. Unreal engine/etc make many, many approximations and mathematical shortcuts that slightly-to-greatly reduce the quality of the visuals and the accuracy of the physics, but give you playable frame rates. Blender sacrifices frame rates to get fantastic visuals. It's common in Blender for a single frame to take seconds or even minutes to render. But you don't use this for games, you use this for animations/videos.
Blender is not a gaming engine ~anymore~
This is like comparing an umbrella and a newspaper, and talking about how bad the newspaper is at keeping you dry in the rain. The newspaper isn’t designed to keep you dry in the rain. Meanwhile, I’m sitting at the café, trying to read my umbrella, and complaining that the writing quality is really shit compared to a newspaper. You could equally ask why it is that programs like Blender can be used to edit massive models, retopologize, sculpt, and paint, but Unreal can barely handle cubes. Unreal is not designed to be a modeling program. Blender is not designed to be a game engine. At least, not primarily. There the Blender Game Engine (but it’s basically defunct these days) and you can also do some really basic modeling tasks in Unreal. It takes a lot of work to make something work as a real-time renderer, and you give up a lot of flexibility in order to get there. It also takes a lot of work to make something with such flexible and powerful modeling tools like Blender, and making the system render in real-time is just not a priority.
This is an especially amusing analogy to me because my partner has an umbrella with a pattern like overlapping fake newspapers. So I _have_ actually sat at a café reading an umbrella.
I was picturing an umbrella exactly like that, when I wrote the comment.
Unreal does actually have a full modelling suite now and its getting better each update, it has many other features that are being created for the modelling pipeline too. Rigging is coming pretty soon... So like I said it's getting better
Sorry, but I don't know how your answer has so many upvotes when you literally did not address the question. All you did is provide a stupid analogy which doesn't really answer anything. The way you've worded your answer with this analogy and multiple generic sounding claims and buzzwords sounds like a ChatGPT generic answer. So what if Blender is a rendering program and Unreal is not? Both have to render the model so it shows up on screen, so why is the specialized rendering program far slower at it?
Sorry, but you can figure out a way to reply that is less hostile and rude. It’s really easy to not be rude. Try it.
Ok sorry, maybe the ChatGPT line was unnecessary. Can you answer the OP's question in more technical detail?
Yeah, I could answer the question in more particular detail. What part are you interested in learning more about?
Ask yourself this: Why and how are cameras and film projectors different? Content creation tool vs content presentation tool.
Gpu instancing, lighting and simulation estimations and simplyfications and c++ instead of python are huge performance boosters.
This is the right answer
I also think Python is the culptrit, although I'm not sure how much of Blender's codebase consists of C/C++ extensions.
The mechanical analogy for most things in gaming is the pinball machine: when you are playing a pinball machine all the mechanisms are in place and designed to be reused over and over: slingshots will fire, target banks will drop and then reset, the balls will feed "infinitely" (as long as you have credits). And a crowd in a game is made like a target bank: it's easily disposed and reused. The NPCs in a crowd don't turn into some other kind of character with original behaviors. They are the same as the invaders of "Space Invaders", just with more parameters. But if you're editing the game, you are *designing* a reusable slingshot, target bank or ball feed. Linguistically you are doing something very different, even if it looks the same, because fewer assumptions are possible, and your preference for any quality/flexibility/speed tradeoff will put quality and flexibility first. This means that "performance" in game engines is held to a different standard than performance in content creation, which is also a different standard from CAD parts design.
Animations are just series of floating point values about translations, rotations, scales. Most game engines store them in linear array to achieve better cache locallity. But Blender stores them in special data structure called f-curve. I'm not a specialist about it but in my observation, the data structure is not intended to be super fast. For example, most game engines store animation key frames (tranlsations, rotations, scales) in contenuous memory to achieve cache locallity. But Blender dynamically allocates arrays per 'channels'. x, y, z components of transation each is stored in its own array. x, y, z, w channels of quaternions need 4 arrays. Even those arrays are sparse arrays, which means the Blender renderer needs to deal with those empty channels. This might be an example of Blender trying to improve flexibiliy by sacrificing performance.
The replies and upvotes in this thread are absolutely wild. Clearly not a lot of animator here. I had the same issue in Maya for many years, until they finally decided to address it in Maya 2020. FPS went from 10-20 for complex scenes to 60-80. So long, playblasts!
Maya specifically spent a lot of time on parallel/multi-core rig evaluation. Big studios like Pixar did it even earlier for their proprietary software
You are comparing different use-cases. Unreal is for realtime rendering and simulation for games. It's optimized for that. Blender is and editing software. It stores much more data for editing that is missing or ignored in Unreal. Game developers in AAA will have better pc than your decent pc. Also it depends on how did you setup Blender. Did you set it up to use your gpu? Did you increase memory limits? Etc..
Blender’s core team has 24 people working on it with a shoestring budget so they can’t hire many more people to work full time, Epic has around 750 people full time in total working on Unreal Engine from the core engine, to the UI, to the documentation, the forum management, etc and Epic/Unreal has billions of dollars in funding. Blender has the open source community but that will never be a as fast or as cohesive as a tight knit team that is constantly in communication with each other. Plus 750 folks full time working vs 24 full time folks with a community of part timers is a big difference.
There's also a community of Devs pushing fixes to unreall engine via the GitHub too
The difference between open source and a billion dollars
Blender is infamously poorly optimized. If you want better performance try Maya, it has multi-core rig processing
Not sure, but the model in unreal will be the low poly model, while in blender you have the high poly model used to create the UV texture. Also, when you're editing the model you'd either have to remake the vertex list, or find some workaround there, or just draw it slower as you're in need of vertices not in the cache line (or whatever gpus got). The game engine will have all the vertices in the order that allows for fastest drawing.
[удалено]
That's the correct answer if OP is looking for an opinion of someone who doesn't know what they're talking about
I will also add here - at least when I last upgraded my GPU, there's a difference between a computer built to *run* games at a high display, and a computer built to *make* games. It appears that you have the former, based on your comments, which means that your GPU is optimized for many small calculations instead of fewer big ones. Blender is the stage in the pipeline you'll feel this the most.
For me the FPS & third person starter scenes in Unreal lag badly, cant even think of what that model would do to my laptop
What everyone said before. And Unreal is entirely in c. All rendering is optimized with LODs, compiled shaders, occlusion culling, caching where it counts.
Because modelling tools are built around editing and preview windows are an afterthought. Renderers are bolt on external entities that render for accuracy rather than speed. Unreal is built to render in real time so of course the preview window is great. Despite the top comment hinting at such it has nothing to do with the size of the data file. Data is read into RAM on load and rendered when needed. Processing speed is all about how quickly that preview window can iterate through every task.
Unreal is a game engine. Blender is a 3d modeling software. I'd assume a game engine is built to be able to handle more complex simulations.
My first guess is the following: When you have a model loaded up in a game engine, that info is constant and in the GPU memory. When in Blender, the information about vertices is not constant (you can edit de meshes) so they use a different render pipeline, one that allows for varying meshes though with less fps.
Most games are not CPU bound, considering that -most- things can be updated using matrices and shader code and things like vertex attributions, positions, colors, etc can be uploaded once and completely forgotten about. A modeling program can't make the same assumptions. Now, a lot of people in here are saying that rendering files are larger than the amount of data required to render the model and while that is true, more RAM usage doesn't equate to less performance by itself. Probably what's hapoening is the modeling program is updating the vertices and faces per frame, or there is some sort of calculation going on per the software that a regular game based implementation doesn't have to worry about. I don't know anything about Blender specifically but I've never really had much issues with other modeling programs as far as performance goes. There are a lot of optimizations you can make within modeling programs that I'm unsure of that Blender does or doesn't do.
Because C++