UE4 engine vs. rendering quality of demos
category: general [glöplog]
Every set of restrictions and possibilities is like an instrument or a language. In whatever domain you operate in order to create your art, that's your language. Game engines, demomakers, Blueberry's Rose, C+OpenGL, C+SDL, m68k asm + Amiga OCS, whatever. Each one of them has a set of means for expression. Limiting the platform's capabilities and entry size is a very simple, but effective way to make very different development stacks comparable in a meaningful way.
The UE4 (or whatever) demo at Assembly only pointed out how lousy the "proper" self-made demos are at utilizing the incredible possibilities allowed by the compo rules. I think what the demo category needs is MORE demos like that to highlight how ridiculously wild the 200 megabyte modern PC demo category is.
The UE4 (or whatever) demo at Assembly only pointed out how lousy the "proper" self-made demos are at utilizing the incredible possibilities allowed by the compo rules. I think what the demo category needs is MORE demos like that to highlight how ridiculously wild the 200 megabyte modern PC demo category is.
Well, if you put all the work in making an engine, and then feel that people cheated by using an existing commercial engine, I think you missed something.
There are reasons for going either way. Making your own engine is of course a great learning experience and is nice if that's what you are into. However, what matters in the end is the pixels and sounds your executable emits.
If you want to compete with commercial engines or even .exe just playing a video, you have to bring some breakthrough. Be it an insanely small size (there are compos for that, even), some interactivity, using legacy or unexpected hardware, making your own hardware, whatever.
I don't see the point in writing your own engine to do exactly what Unity or UE4 can already do. This is mature commercial-grade software now, redoing it is not demoish. You don't bring anything new if your engine is more of the same. However, if you can get things to run with lower-end hardware or do more things with the same hardware, then you bring something and your code is "useful", or, I would say, relevant again.
So, what does your homegrown engine brings that UE4 or Unity doesn't?
There are reasons for going either way. Making your own engine is of course a great learning experience and is nice if that's what you are into. However, what matters in the end is the pixels and sounds your executable emits.
If you want to compete with commercial engines or even .exe just playing a video, you have to bring some breakthrough. Be it an insanely small size (there are compos for that, even), some interactivity, using legacy or unexpected hardware, making your own hardware, whatever.
I don't see the point in writing your own engine to do exactly what Unity or UE4 can already do. This is mature commercial-grade software now, redoing it is not demoish. You don't bring anything new if your engine is more of the same. However, if you can get things to run with lower-end hardware or do more things with the same hardware, then you bring something and your code is "useful", or, I would say, relevant again.
So, what does your homegrown engine brings that UE4 or Unity doesn't?
^^^ exactly
push onwards!
push onwards!
I have to agree with PulkoMandy. The demo compo is supposed to showcase cool audiovisual programs running on the platform and within other limits imposed by the compo rules, most notably executable file size. I mean, if your entry doesn't do impressive stuff considering the platform and the size used, then does it really help that you coded it with your eyes closed and only using your left hand?
remind me ASM 2016 demo compo :
Voyage by Demo Aces ...ripped code with no credit=> Drama....
Gestalt by Quite => commercial engine with no credit => compo winner.
Voyage by Demo Aces ...ripped code with no credit=> Drama....
Gestalt by Quite => commercial engine with no credit => compo winner.
Was the commercial engine used without permission?
It's not even a question about permissions but using 3rd party tools vs. lifting all content. I mean after all of the content (to my knowledge) in Quite's demo was actually produced specifically for the demo, and it does include a big chunk of specifically written rendering code too.
perhaps they add 0.01% of code :)
Quote:
I don't see the point in writing your own engine to do exactly what Unity or UE4 can already do.
Quote:
So, what does your homegrown engine brings that UE4 or Unity doesn't?
Wow! Nice "appeal to ignorance".
You do realize that your beloved mature industry-grade bullet-proof fully-featured commercial package is in principle a collection of algorithms "inspired" by smaller, more experimental engines and open source mathematical libraries, not to mention many techniques featured in demos or intros. Except they claim it to be their own "property", because of nice package around it and some (actually questionable quality) editors and tooling. They are not bad, but not that great either.
Nothing UE4 or Unity is doing isn't in public domain already. You can as well look around and collect even higher quality libraries (open source) doing many things UE4 or Unity cannot do (from general mathematics, computational geometry, physics/fluid dynamics to rendering algorithms).
They just package stuff for people who are doing business i.e. want to focus on gameplay and release the products faster.
There is nothing wrong with it of course, it's usually a "win win" situation, but for hobby project, I will definitely pass on it.
I see no problem with that. If your thing is writing engines, and you are happy with it, no problem. I'm sure it's possible to do better than these tools for demo-engines, even if it is a lot of work.
My own work (on 8bit machines, so the situation is a bit different) involves lots of writing tools, and not this much democoding. But I won't complain that others took the "easy way".
Let people use UE4/Unity/whatever for some time, become aware of the limitations, and then they will see about writing their own engines if that's the only way to move things forward. Or do you think they would stay forever within the engine limitations? If that's the case, it means you have infinite time to improve your engine and show the kids how a REAL demo is made. Eventually your engine should be better than what they have.
If you can't achieve that, you can still write your own engine because that's what you like doing, for the learning experience or because you plan to be hired by Unity someday. But, that doesn't give you a right to complain that others used a commercial engine.
There are rules in democompos and "every byte must be hand-crafted" is not one of them. There are some compos with artificial limitations (usually, a size limit) which tend to prevent such engines. We could do compos with larger size limits (1MB, 16MB, fits on a floppy, whatever) to force people to have some creativity in space saving and dynamic content generation, and this could make these engines even more unfit to the task. But banning some tools because they are "too professional" makes no sense to me.
My own work (on 8bit machines, so the situation is a bit different) involves lots of writing tools, and not this much democoding. But I won't complain that others took the "easy way".
Let people use UE4/Unity/whatever for some time, become aware of the limitations, and then they will see about writing their own engines if that's the only way to move things forward. Or do you think they would stay forever within the engine limitations? If that's the case, it means you have infinite time to improve your engine and show the kids how a REAL demo is made. Eventually your engine should be better than what they have.
If you can't achieve that, you can still write your own engine because that's what you like doing, for the learning experience or because you plan to be hired by Unity someday. But, that doesn't give you a right to complain that others used a commercial engine.
There are rules in democompos and "every byte must be hand-crafted" is not one of them. There are some compos with artificial limitations (usually, a size limit) which tend to prevent such engines. We could do compos with larger size limits (1MB, 16MB, fits on a floppy, whatever) to force people to have some creativity in space saving and dynamic content generation, and this could make these engines even more unfit to the task. But banning some tools because they are "too professional" makes no sense to me.
Quote:
that doesn't give you a right to complain that others used a commercial engine
This!
I actually do not have a problem with some people preferring to go for more esoteric ways of expressing themselves. I am a coder, so I get the appeal of size coding and other things in the same vein. However, I do have problem with some coders complaining about the use of commercial engines. Their assumption, often explicit, is that making an engine is a worthwhile exercise, whereas content generation is somehow irrelevant or, maybe, belongs to another field of creative activity (i.e. not the demoscene). And it is this assumption that actually pisses me off, because almost with no exceptions, these same coders typically have a proven track record of being unable or unwilling or downright lazy to generate good quality content.
I'll begin by saying that I primarily work on older computers, so I don't have a "horse in this race" as the saying goes, but still find the topic interesting.
I don't think that is the issue at all, rather the reverse, the assumption many here seem to hold, that is "coding in itself doesn't have a value, it's the end result that matters".
That, I disagree with. If some coder writes an engine and implements shadows and DOF and whatever, and then wants to create a demo with it, but the artists goes "Nah, that engine doesn't have photon-rendered-subsurface-scattering-thingamabob<tm> that UE4 has, we don't want to use that" - I think the scene has lost something.
I find that pure hobby-created content, be it code, graphics or music has a charm to it.
As I've said before, I think it's the exact same thing as people choosing commercial music for their demos, rather than going with what a scene musician can come up with.
Sure the end result experience might be better, be we have lost a little of the scene spirit.
Quote:
Their assumption, often explicit, is that making an engine is a worthwhile exercise, whereas content generation is somehow irrelevant
I don't think that is the issue at all, rather the reverse, the assumption many here seem to hold, that is "coding in itself doesn't have a value, it's the end result that matters".
That, I disagree with. If some coder writes an engine and implements shadows and DOF and whatever, and then wants to create a demo with it, but the artists goes "Nah, that engine doesn't have photon-rendered-subsurface-scattering-thingamabob<tm> that UE4 has, we don't want to use that" - I think the scene has lost something.
I find that pure hobby-created content, be it code, graphics or music has a charm to it.
As I've said before, I think it's the exact same thing as people choosing commercial music for their demos, rather than going with what a scene musician can come up with.
Sure the end result experience might be better, be we have lost a little of the scene spirit.
Coders making coder-looking demos because they don't have access to graphics artists, artists making demos with Unity because they don't know any coders.
We're doing something wrong.
We're doing something wrong.
OK,... TLDR , but....as far as the utility of the demoscene is concerned,...I would bet that there are quite a few Max or Maya guys who don't exactly like clicking the Render button, and waiting for hours...... at one point I was one of them!
And also there are quite a few suited types up in management, who don't like spending huge sums of money to buy Big Big Render Farms either....!!
If the Demoscene has the power to tackle this, why the hell don't you??
Amongst other things, I would imagine the money involved is not exactly little....?
And also there are quite a few suited types up in management, who don't like spending huge sums of money to buy Big Big Render Farms either....!!
If the Demoscene has the power to tackle this, why the hell don't you??
Amongst other things, I would imagine the money involved is not exactly little....?
Quote:
Their assumption, often explicit, is that making an engine is a worthwhile exercise, whereas content generation is somehow irrelevant or, maybe, belongs to another field of creative activity (i.e. not the demoscene).
Don't forget that the only worthwhile engine is a graphics engine! Even for size compos, most people don't code their own music engines, but use a third party one like 4klang. Somehow that's fine! But use a third party graphics engine, and the shit hits the fan.
Gargaj: why don't you do a little "wanted.scene.org" for them...? :)
Sdw: Yes, I hear you. I totally agree.
It depends on the perspective I guess, but IMHO coder should be the one with the truncheon :-D
Do you think otherwise? ;)
Quote:
We're doing something wrong.
IMO: coders being elitist and artists depending on them (no prod without code, at least before accessible engines), but on the other hand they don't see how they themselves depend on the artist because often all they see is technical achievement and they are blind to the actual content. So there's an asymmetry, because you totally can make a coder-only prod (and just not realize it's going nowhere). When I talked to BoyC about the latest Conspiracy 64k, he just called what zoom does with his code "magic", and that is how it should be. No Truncheons...
and once the demotool is fairly sophisticated..coder are useless :) :)
with our latest demo Guille saw the demo just few hours before the party^^
with our latest demo Guille saw the demo just few hours before the party^^
Shadow, funnily enough, two years ago I created a bit of a stir in the Russian ZX scene when I said that "the code is dead". This actually applies to us, oldschoolers, too. I noticed on numerous occasions now, the number of people who actually understand (and appreciate) what you do code-wise is becoming diminishingly small. Your demos are increasingly end up being watched (and appreciated) by people who have very little or often zero clue about what's happening on the screen. So, the code alone is no longer the mean to the end. However much you enjoy coding, if you make demos to be _watched_, almost no-one's left to watch them, not in the technical sense anyway (the scene is dead, we're all doomed, all that jazz). In fact, I very strongly believe that the situation was just the same in the 1990s, but everyone was much younger and cockier back than.
A year ago I had an argument with one of the well-respected C64 coders on Pouet. He said that he understands what is going on but he personally is still mostly interested in code. Which is fine in my book. What is not fine, are the coders who try to scream and shout to be heard, instead of attracting audiences with their actual demos.
Coder art does not need to vanish or disappear. It just needs to compete against the world whose appreciation for all things visual is leaps and bounds more sophisticated compared to how it was in the 1980s. It means just a bit code is no longer enough. Drawing a fractal will not impress a random stranger. Manipulating beeper to produce sounds is commonly considered annoying. The fact that you learned enough maths to rotate around a cube is no longer impressive. The stakes are now higher. And if people want to make sure that this craft stays relevant, well, you need to support your code by design and graphics and music and all the other help you can get.
A year ago I had an argument with one of the well-respected C64 coders on Pouet. He said that he understands what is going on but he personally is still mostly interested in code. Which is fine in my book. What is not fine, are the coders who try to scream and shout to be heard, instead of attracting audiences with their actual demos.
Coder art does not need to vanish or disappear. It just needs to compete against the world whose appreciation for all things visual is leaps and bounds more sophisticated compared to how it was in the 1980s. It means just a bit code is no longer enough. Drawing a fractal will not impress a random stranger. Manipulating beeper to produce sounds is commonly considered annoying. The fact that you learned enough maths to rotate around a cube is no longer impressive. The stakes are now higher. And if people want to make sure that this craft stays relevant, well, you need to support your code by design and graphics and music and all the other help you can get.
the attitudes behind all this are so silly and so out of date.
unity/unreal aren't so easy. they give you a lot, but a lot of what they give you you don't actually need (in a demo), and there's a fair few things you want that they don't give you, leading you to need to code - or to compensate with loads of assets which are just as hard to make. (unless you start using stock assets. which is a whole other conversation)
but code for code's sake is not a virtue. the goal of many (smart) coders is to code less/smarter - to use a gui for tasks better done by a gui (like .. 3d modelling, animating, syncing - rocket is a tool too). these days a huge range of libs / resources / samples / blogs / examples / etc exist out there to accelerate the process: how many demos use an image loading library or assimp to load 3d models? there's still work involved in implementing all this but it no longer requires inventing of the wheel. there's a great irony in the thought that coders are bemoaning the use of unreal for its "free dof / lighting / etc" while at the same time lifting the implementations of the techniques for their own engines from papers and presentations written by the engine coders of unreal.
while tech is super important in the scene, the ultimate judgement of a demo is not peer reviews of source code or something - it's the visual result.
the joy i find in making demos is the artistic combination of code/technology and art. using code in places where it achieves the result more efficiently than other approaches, or achieving results that never would have been thought of otherwise. how many of our demos, and many others, were shaped by the technology that goes with them, in a symbiotic relationship with the art? if you wanted to make, say, numb res in unity or unreal, how hard a time do you reckon you'd have?
the huge irony in all this is that outside of our little walled garden, a huge number of people use code as part of their creation process. code itself informs the style of their work. people happily mix a whole range of tools and technologies and disciplines, along with code, often within one single person, without feeling the need to label the separate elements. the rest of the world has moved on - it's only the demoscene, where we're still stuck in the mindset of 1993, that these concerns even exist. (that's why the scene is dead!!1)
-smash
(/creator of a commercial 3rd party engine/tool which is used for making demos)
unity/unreal aren't so easy. they give you a lot, but a lot of what they give you you don't actually need (in a demo), and there's a fair few things you want that they don't give you, leading you to need to code - or to compensate with loads of assets which are just as hard to make. (unless you start using stock assets. which is a whole other conversation)
but code for code's sake is not a virtue. the goal of many (smart) coders is to code less/smarter - to use a gui for tasks better done by a gui (like .. 3d modelling, animating, syncing - rocket is a tool too). these days a huge range of libs / resources / samples / blogs / examples / etc exist out there to accelerate the process: how many demos use an image loading library or assimp to load 3d models? there's still work involved in implementing all this but it no longer requires inventing of the wheel. there's a great irony in the thought that coders are bemoaning the use of unreal for its "free dof / lighting / etc" while at the same time lifting the implementations of the techniques for their own engines from papers and presentations written by the engine coders of unreal.
while tech is super important in the scene, the ultimate judgement of a demo is not peer reviews of source code or something - it's the visual result.
the joy i find in making demos is the artistic combination of code/technology and art. using code in places where it achieves the result more efficiently than other approaches, or achieving results that never would have been thought of otherwise. how many of our demos, and many others, were shaped by the technology that goes with them, in a symbiotic relationship with the art? if you wanted to make, say, numb res in unity or unreal, how hard a time do you reckon you'd have?
the huge irony in all this is that outside of our little walled garden, a huge number of people use code as part of their creation process. code itself informs the style of their work. people happily mix a whole range of tools and technologies and disciplines, along with code, often within one single person, without feeling the need to label the separate elements. the rest of the world has moved on - it's only the demoscene, where we're still stuck in the mindset of 1993, that these concerns even exist. (that's why the scene is dead!!1)
-smash
(/creator of a commercial 3rd party engine/tool which is used for making demos)
Quote:
IMO: coders being elitist and artists depending on them (no prod without code, at least before accessible engines), but on the other hand they don't see how they themselves depend on the artist because often all they see is technical achievement and they are blind to the actual content. So there's an asymmetry, because you totally can make a coder-only prod (and just not realize it's going nowhere). When I talked to BoyC about the latest Conspiracy 64k, he just called what zoom does with his code "magic", and that is how it should be.
/thread
you have to realize that the context of demos has expanded. the scene isnt dead yet... but very well could completely die in a few years. we need to either embrace and open a category for game engine demos or the "OG hard boys" need to make works that a commercial engine would never dare enable someone to make! i.e. VIRUS-LIKE
Quote:
Your demos are increasingly end up being watched (and appreciated) by people who have very little or often zero clue about what's happening on the screen."
Well, I guess this is where the difference lies - I don't see any point in trying to impress viewers who doesn't understand what is going on (and have no interest in gaining that knowledge). I really don't care what random YouTube-watching teenager thinks of a demo, what matters is the people who actually know what is going on. This might be a diminishing group, but considering the attendance numbers at for example X2016, a C64 only party, there still seems to be quite a lot of people who are still have an interest in the "traditional" scene.
Quote:
but code for code's sake is not a virtue. the goal of many (smart) coders is to code less/smarter
That depends if you are coding just for the end results sake, or for the feeling of having created and actually understood something.
As I don't work on the newschool/PC side, I can't take any example from that, but for me, I did my first filled 3D routine for the C64 in this demo. It was released in 2008, and used techniques that were probably known in 1992 or 1993. If I looked around, I could probably have found some code on codebase64 perhaps that I could have dropped in and had the same end result.
But for me, working out the ideas and algorithms behind it, actually *understanding* how things work, and then implementing it, gives a much greater sense of accomplishment.
About focusing only on the final result versus taking tools in consideration:
We have a "what" versus "how" question. The what is the final result, the demo you can see on the screens. The how is the creation process (including the tools). Saying "it's great" is totally different from saying "It's great given the tools used". When people outside of demoscene talk about demos, it's often linked to the how : "look this Mercury space adventure, it takes only 64kb!" --> 64kb is a how. 8088 MPH resonated outside of the demoscene not because it competes with Pixar movies, but because the hardware is limited (the what given the how).
Conclusion: The how matters.
About demo coders being a deprecated concept
@introspec, not only demo coders have to face they don't impress anymore the public: It's the same for artists. If you only judge the final result with no respect to the creation context, what comes out of demoscene is crap for most of this world's inhabitants compared to mainstream artists. People won't pay to see or listen to what we're doing, or even spend time to watch it for free. I know some will give me 1 or 2 exceptions out of thousands of productions, but face it: we are a microcosm with rules and appreciate what is done because we know and understand the rules (gosh! jazz musicians stuff).
Conclusion: The how matters.
Should commercial engine-based demos join the Wild category?
Drawing the line becomes complicated. Smash is right: Lots of coders copy/paste from NVidia's GPU Gems articles and then complain about people using Unreal... You can never know how much of a demo has really been done by its authors. So auditing the code or tools is almost impossible. Size and platform categories are fine as it's easy to audit. As already suggested by many, I would limit demos to a maximum file size, above which it would switch to the Wild category.
The how matters.
We have a "what" versus "how" question. The what is the final result, the demo you can see on the screens. The how is the creation process (including the tools). Saying "it's great" is totally different from saying "It's great given the tools used". When people outside of demoscene talk about demos, it's often linked to the how : "look this Mercury space adventure, it takes only 64kb!" --> 64kb is a how. 8088 MPH resonated outside of the demoscene not because it competes with Pixar movies, but because the hardware is limited (the what given the how).
Conclusion: The how matters.
About demo coders being a deprecated concept
@introspec, not only demo coders have to face they don't impress anymore the public: It's the same for artists. If you only judge the final result with no respect to the creation context, what comes out of demoscene is crap for most of this world's inhabitants compared to mainstream artists. People won't pay to see or listen to what we're doing, or even spend time to watch it for free. I know some will give me 1 or 2 exceptions out of thousands of productions, but face it: we are a microcosm with rules and appreciate what is done because we know and understand the rules (gosh! jazz musicians stuff).
Conclusion: The how matters.
Should commercial engine-based demos join the Wild category?
Drawing the line becomes complicated. Smash is right: Lots of coders copy/paste from NVidia's GPU Gems articles and then complain about people using Unreal... You can never know how much of a demo has really been done by its authors. So auditing the code or tools is almost impossible. Size and platform categories are fine as it's easy to audit. As already suggested by many, I would limit demos to a maximum file size, above which it would switch to the Wild category.
The how matters.
