Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - RAV
Pages: 1 2 [3] 4 5 ... 30

21
2D & 3D / Re: Value Studies
« on: August 12, 2017, 02:42:58 pm »
Great article. Thanks for sharing your experience.

It also sheds some more light on the wisdom of the old masters in oil painting.
I have read often how they would remind their students to emphasize pencil practice even as oil painters.

This had many reasons of course: The sheer volume of quick practice, the difference in the costs of it, and I also suspect the importance of learning Value, simply by the pencil's nature of not allowing for Hues. You had no other option than to develop an eye for seeing Value, make use of Value to draw the scene, and learning how to use a pencil for creating Values.

The masters did not need to recommend Value study, they recommended Pencil study. Better focus on Value was implicit to the correct choice of tool. When trying to drive a nail into a wall, you don't choose a spoon or a sponge, you pick a hammer. And that's true for how you study an aspect of art.

And the simplicity of the pencil was unambiguous in what matters, what you would practice. Today we face a different problem: our tools seem almighty and very complex. For learning, it is difficult to discern the order of things. But I believe there is a hierarchy in every domain of knowledge, and understanding that helps you learn it faster.

Thus nowadays, it becomes more about understanding the conceptual system of art, and reducing the functionality of our tools to our given needs accordingly. Facing all these possibilities right from the start, you need to learn what to focus on and what you can meanwhile ignore, for a given task. The idea of Value Study reinvents the old pencil practice within a powerful image program. You better know how to tune your tool towards a focus study.

With colour, we can observe that when trying to create an image only by Hue it is much harder to make an advanced scene than by trying to create it by only Value. So clearly, Value takes prescedence over Hue in the basics of what it means to construct an image, and it's the fundament of understanding colour. This reveals the treachery of the HSV name, since it implies the importance of Hue coming first. But sorted by priority, it should be named VSH.

Recognizing the importance of value does not mean Hue is easy, though. In nature, objects and light sources have both archetypal Hues, but it's much more complex than Grass = Green. This in itself is subject to intense study, especially how all these objects and lights interact for the final Hue. For example, one common mistake is trying to create daylight change only by Value. Thus, after you learned to understand the world by Value, you have to rediscover the world of Hues.

In terms of what practice has what core meaning compared to other practices,
You might even say that classic painting basically focuses on Hue Study.
Pixel art is basically focus on strict Pattern Study.

22
General Discussion / Re: Hackable pixel editors?
« on: August 04, 2017, 10:51:40 am »
The thing I like to avoid most is when the issue boils down to either:

Someone arguing your're a bad person for not releasing your source. It's unethical. You should be ashamed.

And the other way around some critiques on Open Source projects come across way too ungrateful
and disparaging and blind towards the accomplishments and benefits they do bring to the table.


Besides that though, there are plenty of valid critiques on when proprietary products fail for various reasons.
As much as you can argue cases in which open source projects aren't quite where they need to be for serious consideration.

It can also be discussed if there may be even a causal relationship to these problems by virtue of the development paradigm.
Some might say, there is no downside to this or that. It's better on principle, it's just that people are not enlightened enough to take more advantage of it.

I believe that software development is a problem that exceeds pure technical consideration, because in the end the coders are just humans too.
So there is all kinds of questions about psychology, culture, motivations, economics, the situation, etc, that I think are important to factor in.
I think that there are at least associative relationships between these further factors and the development paradigms, that make the issue very complex.


As an example, I believe that a person's motivation is the most important key to the success.
We can then look at factors of motivation, and how powerful their psychological effect is.

Imagine that working on a snippet of code means, you are fully responsible for it, so far that you are held fully accountable for it. If the product succeeds because of your code, you may get a promotion and a higher income. If it fails because of you, you may lose your job, all your money. You may even go to jail in some cases. The company may sink, with all your colleages and friends. So you are sitting there, and maybe you give your code a couple more looks. Make a couple more test runs. Maybe listen more to customer complains. Maybe you even feel a greater sense of duty to do work that's not always fun and rewarding. The stakes are high, and your name is on it. So one person, from motivation to qualification, may put more value into a work than a hundred hobbyists.

Now I don't want to make the issue too simple. Because in a different scenario, that employee might be underpayed and frustrated with the job, feel like a cog with no say, etc, which also is bad for motivation. And in a project as a free hobby, you might be motivated because you just love to play with it and interacting with other creatives, and feel responsible for it as it grows on you.

Then we can argue about the difference of these as either a fully integrated development paradigm, or a mere fact of having companies release their sources. But there are such a huge amount of consequences to that too, what this means for companies and investors, one might not appreciate at first either. Then the discussion is at danger into devolving into fundamental critiques on society and life itself, it can get pretty awkward.

23
General Discussion / Re: Hackable pixel editors?
« on: August 03, 2017, 08:06:26 pm »
But to specifically address a point I think you wanted to make most:
Even with the very best intentions of all parties for establishing a common standard,
there is a high likelyhood of things getting so messed up simply by mistake
and individual problems of execution, it may as well not be standard.

Plenty of examples, yeah. It again is a problem of scale, and we haven't fully figured this out yet.

Because this is not simply a problem of coding, altogether it's a fundemental problem of life.

We haven't really figured this shit out anywhere.

The attempt to create world wide standards that truly work without conflicts, may as well be the attempt to create god.

You shit flinging monkeys.


I don't even know what's worse. At least trying or not even bothering.

And is succeeding not our ultimate doom? The end of life's purpose.

To search. always search, struggle, with your own little life.

You have your peaceful standards when you meet your maker.

Just watch out that you didn't die because of boredom.

Since it's all just the same to you,

sitting there in silence,

until nothing's left,

to live for.

24
General Discussion / Re: Hackable pixel editors?
« on: August 03, 2017, 05:50:02 pm »
The few moments you appreciate a monopoly setting standards. :p But yeah, I also think it's just part of life. Part of a coder's job. Dealing with different systems. So get used to it, painful as it may be. Many of these problems are pretty much unavoidable, no matter the paradigm, because that's just how humans do things. Unless someone makes it their business to bridge these differences for you with their middleware, engines, libraries, frameworks, etc. But even so, you could say Browser were meant to be like that with their standards, and see what chaos we got anyway. This is just what happens when you got all these people doing their thing. At some point you think about "how can we make something more interesting? How can we set ourselves apart from the others?" and there you go, doing things differently, "better". Kinda funny how this discussion meets with questions of Pixel Art definition. You could also describe that as a problem of standards. And just like artists seek to make something special, so do technicians. And then others have headaches how you can connect all that in one place.

25
General Discussion / Re: Hackable pixel editors?
« on: August 03, 2017, 01:27:26 pm »
Not sure where this thread is going, but I guess we may as well have some conversation.



I've dealt with plenty of platform specific bugs. If you rely on multi-platform frameworks that abstract from specific hosts, you can avoid a lot of this,
but even so there can still be problems. At any case, I guess that the overall number of bugs in the actual program core is usually higher, though.

Your program is of course embedded in a greater host system.
And each host may have different logic behaviour, in two ways:

Either it is obviously different in the interface.
So the part of your code that deals only with that host may have bugs that the software doesn't have on another host.

Or there are unspecified differences in the behaviour of the host implementation underneath.
An example I encountered were graphics driver problems I had on one system, that I didn't have on another.
The code was the same for both, and although valid in principle, needed additional provisions on the other.

I still have to deal with some such issues. Unfortunately, this time with the open source drivers on Linux.



There is a lot of things I like about open source projects, even though I don't see in it the greatest solution to every problem.



The Open Source movement is sometimes percieved as counter to proprietary industry.
But much more often it's complementary forces of something greater.

In reality, the industry has been very supportive to Open Source projects.
Many of the best projects have a good involvement with various companies.

Linux would not be where it is now, without it.
Some might say, it should be more, so they're bad.
But in many ways it's been plenty enough in my opinion.

The reason is simple: there is a need for Open Standards.
Open source software is part of the industry infrastructure.
At least with that code, you can bet it works pretty well.

However, agreement and compromise among many people is difficult to achieve,
and the need for that in a greater community project can also stifle development.
So it's not about what is the ultimate development pradigm.

Cooperative behaviour is not exclusive to just one side. And there are many ways of going about it.
At the same time, open source projects also have to compete for public interest, because it is voluntary.

And while this is great, that's also a challenge for Open Source development, as it is for anyone.
But it hits Open Source especially hard, because of its pronounced freedom, while limiting ownership.
This is not simply about greed. The question of ownership already starts with who directs the project which way.
And the often inconclusive answer to that has many difficult consequences.
The usual answer is forking development, so everyone can be happy in their own way.
But that too has caused many problems with splintered and weakened projects.

And that makes for weird contradictions. In theory, OS on average should be much more stable and save and service friendly, since anyone can look into it.
In practice it often isn't. Because not enough people are motivated to look into it, and there are big problems from a lack of accountable hierarchy structures.

So there have been several huge security holes that lasted more than a decade, and were a total embarrassment when discovered,
of a kind so bad you never saw happen on equivalent proprietary solutions in the first place.
Or terrible legacy constructs difficult to get rid of because of community politics.

The most important factors to good software is the combination of developer engagement with user feedback. That's the sort of Open that matters most.
And the idea of voluntary community service for the greater good is thousands of years old and was not invented by radical neckbeards on the internet.

Having said that, I'm glad these projects exist.

26
General Discussion / Re: Ramblethread! A brainstorm approaches!
« on: August 01, 2017, 08:37:37 pm »
Well, I like what you got there.


I am a bit startled by the latest /r/pixelart discussions on Reddit, regarding rules on what pixel art is permissable. That's not the way I want to discuss the issue. I want to talk about potentials.

As it concerns PixelJoint, I was willing to grant them the freedom to enjoy their more narrow notion of pixelart. There are various arguments to be made how their definition plays along their particular  website design, and the long history of dedicated community. I was even willing to interpret its rules as that of a virtual Game Console: in the past, even though there was no official definition of pixel art, pixel artists were very much restricted by the rules of the given machine. Don't like the rules? your pixel art won't make it in. So that sort of tyranny of what is "allowed" never really changed. But what did change is how much sense the rules make. Rules born of physical reality, what you want to achieve, and the hardware and software you got for that, are easier to accept than just about any rules some guy comes up with for no particular reason. But even if we grant that in a way PixelJoint was a virtual equivalent to an Atari console, in terms of that there are clear rules in order to organize communal activities in a certain sense... there were still other consoles on the market with different rules... Don't like an Atari? Pick a Commodore. Pick what you like. Go to a different website. There better be a different website. With different rules. Certainly there is a market for that.

This is a question of scale. Scale changes everything. Some ideas work small, but completely fall apart in big. And PixelJoint's idea of purism is such an idea.
It simply cannot work in a large scale environment. It turns from fruitful dedication to pointless tyranny, and costs too much creative opportunity. Pixel art too needs a free market of diverse ideas.

In smaller environments, a higher clarity of the situation enables you to be closer. Sharing more values effectively enables you to work closely together on critical and sensitive things.
But in larger environments, a higher diversity is a natural given. The relations and rules must be more relaxed. The expectations and requirements on each other reduced, in favour of freedom.

And in addition, it should be taken into account what a place is made for: Educating about pixel art craft? Researching the market of pixel art? Showcasing pixel art genre? Working on a pixel project?
Depending on what the place is for, exposure to diverse art, or concentration on certain work, may take precedence in its mission.

In terms of what Reddit is, from design to scale, a very narrow notion of pixel art does not fit well. It did well for years without it.
For r/pixelart I would suggest a less centralized definition and planning, and more an Accumulator of diverse ideas in the genre.

In so far, if there really need to be rules for the reddit sub to protect it from totally devolving into a mess of nonsense, the thoughts you have given above seem like an acceptable compromise.
But I also like the technical solution eisha talked about, a sort of tagging that instead of completely removing things on search, just slightly fades the threads.

But well, the market will sort itself out anyway. People will go where the excitement is, on the fringes of "legality", be it social media, or new popular sites like ArtStation. where pretty much anything goes. And really, 99% of the pixel art games in the last 10 years do not follow purism. Even reddit won't change that. If Reddit takes itself too important, it will share the fate of any other former giant in a free market. Oh how deep fall the mighty, when they cannot keep up with the innovations and interests of the people.

27
2D & 3D / Re: Realtime Rendering of 3d Meshes as Pixelart
« on: July 20, 2017, 11:52:36 pm »
It's true that these screens look less clean than the shot he posted just before. But it got me thinking a bit. There's been talk lately about bringing back a bit more "dirty grit" to pixel art. I kinda wonder, if making it as clean as possible should even be the goal, or if reveling in a slightly uncontrolled grit of techniques is an aesthetically interesting deviation for his project, pleasing in its own way. Maybe in the end it comes down again to how readable the critical action in a game would be. For example, I find it slightly difficult to focus on the ship in these latest shots. Still, getting some level of grit just right could be a strength of its own, further setting it apart visually.

28
2D & 3D / Re: Realtime Rendering of 3d Meshes as Pixelart
« on: July 20, 2017, 11:12:14 pm »
I like it on every dimension, from tech to art to even your game idea. Altogether really selling me on this.
There are so many cool things happening with pixel art in recent years, and I think you got a strong positioning in all of this.
And I wonder if even 2d games could somehow benefit from this. It could reign in the colors from a lot of the effects these days.
Well, the genre is getting interesting for sure. Trying to make some greater sense and integration of that all will be a fascinating challenge.

29
2D & 3D / Re: Realtime Rendering of 3d Meshes as Pixelart
« on: July 20, 2017, 09:16:12 pm »
Good things take a while, and this is looking great. You're addressing a lot of the concerns from the start. The image quality just keeps going up.

What kind of end product do you have in mind for this? Is it more a general pixel converter, or are you gonna make a game of this?

30
General Discussion / Re: Ramblethread! A brainstorm approaches!
« on: July 04, 2017, 02:44:28 pm »
The graph is useful for discussing the problem.


I think that what makes pixel art is a multi dimensional problem.
And I think pixel art should be made interesting on multiple dimensions.

The use of colours was mentioned earlier. And I also think this can include how else the properties of the pixel grid are used.

And how well is the functional design of the pixel scene.

Other than High Art pieces, art usually is made to specifications. Most pixel art is game art.
I personally even think that game art is the best reason for why you would do pixel art.
Or more general Application Art, it pretty much is how it was born, what drove it the most.

People made software and wanted to make it look cool.
They had limited technical resources to program with, which translated to limited resources to make art with.
Thus the key consideration of pixel art always was to make the most use of the given pixels towards the requirement.

And this principle got aesthetically generalized on one hand. Or pushing new boundaries made for other critical resources limiting it again.
Or another definition of resource appeared: development resources. The ability to make indie development effectively possible.



So the questions I see in regards to what is pixel art:
why is one style more representational and defining of pixel art?
how well does the art choice work towards which requirements?

And there's very good reasons for the norms we have today.

I see in the graph a lineage of usefulness in digital arts.
I don't actually think the graph is balanced as it implies.
And I don't think that all these are just arbitrary ideologies.

The middle has the greatest number of reasons for why you would do pixel art for most applications.
Going to the left noise, the reasons get fewer for why you would do any art like that.
It sure can look very fascinating as an effect, and there can still be a very good reason for why you do it in some case,
but in the greater scheme of applications, it can only be a niche. At its best it is a gimmick, at its worst its useless.

Going to the blurry right, you have a great many more reasons why you would do art like that.
And many of these reasons are also very good for why you should do something else than pixel art.
Digital art did not evolve from the middle towards the left on the graph. It evolved towards the right side.

Most cases of application for pixel art require the clarity of the middle.
It's what works best for most people, it's the norm for good reasons.

Pixel art has the strongest identity and greatest use in the narrow part.
Most people that want to create pixel art, will want to know how to create that.
The defining quality of that organically rises from these greater interests.



Then we also have the priority of factors in classification.
Many titles that use blurry after-effects are in fact created as pure pixel art.
So we often have a difference in appearance, but not necessarily on a creative level.

This is one critique I have on many modern implementations:
The assumptions that applying some effect is a meaningful progress to the art.
But there are still more interesting endeavors in the creative core substance of pixel art,
that most people distract themselves from too much by concentrating on surface effects.



Then we have the question of "What pixel art is relevant to most people" or "What PixelArt are you allowed to do".
Fortunately though, the second question is irrelevant today. Very few people care anymore what is allowed on PixelJoint.
No one's success or failure in the business depends on what is seen as proper pixel art today.

However, that some forms of pixel art are more successful than others, can't be changed by anyone's definition.
You create something meaningful, and either it catches on or not. And then you observe the market and classify by interest.

Pages: 1 2 [3] 4 5 ... 30