Ok, yes, a bit controversial. What I mean to ask is…assume (correctly) that for the purposes of this rant, video games and real-time graphics, and virtual reality are BIGGER than ever, and getting even bigger every year. More powerful computers cards etc… OpenGL renders are getting REALLY good. A screen capture from a modern super high end game approaches render quality. Think about 10 years from now. I’ll assume I’ll have a lot of support in this particular area…
So why is it that almost every resource anymore - every addon, etc…is for Cycles? I just never understood why a flat picture or an animation is more interesting than walking around in a world. Who cares about a picture? I want to wander around that picture, and interact with it. Is the Blender GE dying? Mike Pan does some really great work with the GE - I own his easy game add on, which is a notable exception to my rant. But really - I find little enthusiasm for the GE anymore - it’s all grainy, slow ass render times cycles. Press a button, wait 40 hours…picture. Shit, my flowers are off. Repeat. I don’t get it. It just seems like younger people would be more interested in real time graphics. Nope. Here’s my render of a manga girl. Only took 100 hours to render, and don’t mind the grain. Want another view? Come back next week. Here endeth the rant!
3D medevil, please contace Mr. Ton, and ask him to integrate lobos render into the game engine, and have the material workflow from blender, export a nodgraph, and not expose undo complexity to the end user, unless they wish to*
when you use materials like they are now,
they are more like sketchfabs pbr render, and when you press P, it uses the same gamelogic but a new render, have you seen this? https://github.com/luboslenco/cyclesgame
Interesting. Seems like a long way off, but at least someone cares. I know ZERO about coding and most everything to do with engines. I’d like to see more interest in real time graphics in general, and that guy seems to be on the right path. Thanks for sharing.
Are you talking about Cycles (which is a specific render engine) or are you talking about rendering by itself?
Comparing the BGE (which has realtime rendering) with Blender (which provides detailed rendering) is possible, but you need to define what exactly you want to compare. They both have complete different goals. Because of that they have different requirements. This does not exclude that they have a lot of shared attributes.
For example:
high detail
fast rendertime
While these are goals for both (Blender and BGE), they are not independent. There is a reciprocal relationship between them. This means, when you get fast render, you get less details and when you get more details you get more render time.
The relationship might shift while technique makes progress, the relationship still remains (it is simple math).
Lets look at our applications
the focus on Blender render is on high detail
the focus on the BGE is on nearly realtime (render time below 1s/60)
What to choose depends on what you want to do.
The funny thing is that you might get both. E.g. you render high detail into your textures with Blender, and show it in nearly-realtime with the BGE.
Because the focus on Blender is high-detailed rendering.
There is a lot of interest into the Cycles renderer (which is one of many). So users take the open-source route and provide additions.
Because you did not contribute add-ons for the BGE (just a joke).
The point is … why you care cycles, when you want to work with the BGE?
Are you talking about Cycles (which is a specific render engine) or are you talking about rendering by itself?
Comparing the BGE (which has realtime rendering) with Blender (which provides detailed rendering) is possible, but you need to define what exactly you want to compare. They both have complete different goals. Because of that they have different requirements. This does not exclude that they have a lot of shared attributes.
For example:
high detail
fast rendertime
While these are goals for both (Blender and BGE), they are not independent. There is a reciprocal relationship between them. This means, when you get fast render, you get less details and when you get more details you get more render time.
The relationship might shift while technique makes progress, the relationship still remains (it is simple math).
Lets look at our applications
the focus on Blender render is on high detail
the focus on the BGE is on nearly realtime (render time below 1s/60)
What to choose depends on what you want to do.
The funny thing is that you might get both. E.g. you render high detail into your textures with Blender, and show it in nearly-realtime with the BGE.
Because the focus on Blender is high-detailed rendering.
There is a lot of interest into the Cycles renderer (which is one of many). So users take the open-source route and provide additions.
Because you did not contribute add-ons for the BGE (just a joke).
The point is … why you care cycles, when you want to work with the BGE?
The Blender developers are aware of the lack of attention the game engine has gotten. That’s why Ton suggested long ago to bring it closer to Blender itself and e.g. to use the same rendering code for both the viewport and the game engine. The developers are currently working on it. The first step is to modernize the viewport by using a newer OpenGL version.
The very nice real time rendering you see in games is really just a series of very clever tricks built specifically for the product in mind. Cycles is not a series of clever tricks, it is an accurate simulation of light rays hitting object and coming back to the camera. Cycles is far less prone to breaking than real time lighting techniques, can be customized to a greater degree, and is also far more consistent.
If I’m getting the topic right (and I’m not entirely sure of it) it’s a very interesting one. Is there any room for a convergence between real time renderers and… non real time? How are they called?
I know that the gap between the two is still big, a 3D artist can spot the difference between the results of the two in a second.
I could barely tell the difference between a hand made painting and a photo. The thing I find interesting is that I am the consumer of the final product: if a realtime renderer can produce an image that fools me, then it may be a suitable tool for stuff like “Star Wars: Rebels”.
Concerning the convergence of engines, how they all work - that’s not what I mean to ask here, though it is certainly interesting. I’m simply wondering why wandering a 3d world isn’t as interesting as looking at a flat picture, or making one. Real time, virtual reality, a crazy future where we make films by live acting as motion captured 3d characters, and the audience can look around and BE in the live production - these things excite me. Or Imagine a game engine so fast, so fluid that you could look around what today is a simple JPG or PNG. A 2d render of an old barn…not so much.
And point takem - I could make add ons. Don’t know how…not bitching or whining. Just…I wonder why there’s so little enthusiasm for TRUE 3d. Immersion. I’d pay money for great GE add ons. And have. That’s all I mean. Just curios.
Game engines are developed very fast these days to constantly extend the capabilities of what is possible. There are huge investments being made to improve graphics, animations, physics and basically everything else that is relevant to give people a better experience. There is a huge amount of VR research being done to allow people having a better 3d experience. Though due to lack of computational power and still lots of potential to improve the performance, it will be almost impossible to reach a comparable experience to what is currently possible with just one screen.
A still very young achievement is physically based rendering. It is possible to get almost the same results with less expensive rendering techniques, but physically based rendering allows you to create an extremely consistent appearance for changing lighting conditions. This wasn’t possible before that. It was a lot more work to get something comparable and usually it still didn’t work as good.
Thanks to physically based rendering, real time graphics become much more believable. There is a lot of enthusiasm for this kind of development, but it takes time and very often, it can only be used on high end computers and it will take years until it can be used on standard computers.
There is also extensive research going on for real time global illumination. But this can only be used if it is baked upfront, which is for sure a limiting factor.
That all sounds great. Years ago I played my first 3d game - years after Packman. I didn’t play video games except arcade games occasionally as a teenager. So…Skip to 2001. I was 28. I played “Blade of Darkness”. Really blocky, super low-poly, no normal maps, no specular shading - texture face mode, but oddly real-time reflections and shadows for the characters (I assume everything else was baked). I was hooked. I started looking for whatever program those people had used to make that game. Maybe someday I too would be able to make a 3d cube with a texture on it, and move around it in real-time! Wow! Now, even though the GE seems to be in some kind of transition, I still find it infinitely more interesting than rendered images. I make castles you can walk around in, as opposed to look at a picture of. No offense to rendering. But I see it as a step up - a little tiny bit closer to the real thing than renders. Sure, I get that renders are more realistic. But in a way, not really - reality is 3 dimensional, so a less photo real object in real time, to me, is more realistic than an ultra real 2d rendered image. If that makes sense.
Blender material workflow is bad, limitative - an ultimate opposite to what PBR does. We need to use nodes(like lubos does already - he uses cycles nodes).
Lobos says he would not mind at all if we use his render, to replace the game engine render.
First however we would need to use the cycles preview GLSL (so things look like they will look in the game engine in the viewport)
then we would need the material systems that we have currently to be replaced with a PBR material input setup, and when you press P, convert the materials to a node group.
Much of bge.render would need re-written however so that you can control the new engine render instead***
It’s a lot of work, but not near as much as writing a new modern render from scratch.
one answer as an example: my daily job is making photorealistic images that will be then printed on paper. That’s what many people do for money. In this sense I’m interested in Cycles, and the quality it gives me spending little time preparing my scenes. Maybe some RT engine is already able to deliver that level of photorealism, but i think it just takes a lot of time to set up anyway.
btw, Ton latest message in the mailing lists might open a large horizon for viewport re-design (you know, optimization, shading and so on) so let’s see
Totally on rails, prerendered, (basically they recorded something like cycles to a bunch of angles, or even still scenes)
He is being silly… you say you want real time that is pretty, that is totally possible and people are working on it from a few different angles.
you have the viewport project - this will give BGL (Blender viewport and game engine drawing code) a significant advancement and move to modern shader tech
we also have what the UPBGE folks have been tinkering with, like viewport instancing of geometry, and materials, to save render passes, and then there are things like that new game engine I was talking about.
Basically He said the bge developers are free to grab anything useful they find inside his engine…
and his engine looks gooood.
Some hybrid of the two engines could lead to a fast, stable bge.
