This post has trivially to do with arm-netbooks.
I'll say, risc architectures would be optimal for an ideal virtual machine that minimizes hardware awareness in userland, which has to do with Urbit, and; has to do with what I perceive Blender could be.
Blender to me, long seemed designed for discovery learning. I perceive that as, 'the [infamous] Blender way'.
Why none could properly document nor tutorial'ize Blender. Always intended as a practical toy. Never to grow-out of...
Until v2.8 .
Violating potential for discovery learning, with a persistent toolbar where previously only the toolbox-selecting-multitool and the window-clone-or-close-multitool persisted, remaining the only tools needing persistence.
Much like the Linux kernel aims for ideal hardware implementation, Blender should aim for ideal graphics processing for any given hardware. Named blender-modes shouldn't exist; only two blender-modes should exist: "Render" (for static media) and "Engine" (for dynamic media). Likewise, as the Linux kernel seeks to maximize its hardware targets, so too should Blender in to perpetuity. Even for hardware unpractical for rendering or compiling, Blender should integrate EVM render and EVM compile, or alternatively SaaSS (but only mainline SaaSS after EVM etcetera, On Principle).
Blender shouldn't integrate a programming environment designed for aspiring programmers; Blender should integrate a "toy language" as a programming environment that aims to enable critical fun and intuition where even seemingly random language assortments generate interesting affects that encourage further exploration.
Like every OS should have boot-to-browser as a function, so too every OS should have boot-to-blender as a function. All the while, both interfaces should encourage discovery learning.
v2.8 removes "game engine" mode, as-if to say "yeah, we're narrowing our scope, so what?" while almost imagining "competing in the here-and-now is more fun than grasping at a future we won't get to witness ourselves".
CC0
Correction, Blender ditching its game engine seems like misinformation I got.
Seems to actually be following the path I recommended by renaming it interactive mode, since game logic can be useful for creating static animations too.
That sounds exciting. Imagine playing a game and being able to setup/program cameras where ever to capture whatever, and if an otherwise unnoticeable area is poorly modelled or textured then you can remodel or retexture it yourself in the same floss environment you might if you wanted to animate in or resume playing from.
My other criticisms about the persistent toolbar and the programming environment, I still standby. For any who might argue persistent save button, I would argue that blender should write its state to file, to make needing to save for any reason besides naming, obsolete.
Even otherwise, coordinating discovery learning is more important.
There seems to be some ambiguity about whether Blender will develop any interactive logic which can't export to an MIT or otherwise permissively open sourced or closed source game engine, so additional game code doesn't need released under GPL.
That's concerning to me, since of course games should release source code.
In that case, I renew my criticism about the engine's development direction, though albeit Blender seems somewhat embarrassed by the decision with how they seem to mock it up as not giving up when that's what it seems.
Dynamic media designing kits fail on the general abstraction level, deciding when what information is useful. Godot succeeds considerably by making specialized game logic scripting languages. These languages are stereotyped as easy to make & easy to learn, so raising complexity past a certain degree, triggers many anxieties about distraction from the art of design for the one on the learning side of the coin.
Perhaps Urbit lies in that realm separating a script's complexity from a program's complexity without incorporating any familiar elements from projects trying to gradually close that gap rather attempting to close that gap almost all at once. An artificial gap surely, that the only barrier preventing closure amounts to bias.
On Sat, Sep 8, 2018 at 9:51 PM Jean Flamelle eaterjolly@gmail.com wrote:
In that case, I renew my criticism about the engine's development direction, though albeit Blender seems somewhat embarrassed by the decision with how they seem to mock it up as not giving up when that's what it seems.
Dynamic media designing kits fail on the general abstraction level, deciding when what information is useful. Godot succeeds considerably by making specialized game logic scripting languages. These languages are stereotyped as easy to make & easy to learn, so raising complexity past a certain degree, triggers many anxieties about distraction from the art of design for the one on the learning side of the coin.
Perhaps Urbit lies in that realm separating a script's complexity from a program's complexity without incorporating any familiar elements from projects trying to gradually close that gap rather attempting to close that gap almost all at once. An artificial gap surely, that the only barrier preventing closure amounts to bias
I'm not sure I entirely follow your reasoning, but have you heard of Armory3D? It is a game engine that is being developed that integrates into blender.
Nodes are a helpful visualization tool Access to underlying code and an interpreter still is very important. Seems to rely on standardized languages and its own scripting language seems to have many esoteric variable names.
I'm trying to express that more important is enabling others the ability to express themselves in a way that can be saved as data and later interpreted, rather than offering them tools which esoterically enable fast development and output.
Dream/vision first, actualization later. The art first needs recorded, then the art can get beautiful form.
arm-netbook@lists.phcomp.co.uk
-
Jean Flamelle -
Louis Pearson