449 karma · joined April 15, 2012
Is an 'inland lake' different to an 'offshore lake'?
'Uncanny valley' issues related to face-based (as well as body motion-based) realism in simulation for both games development and video production, whilst there have been recent very significant advances in addressing them are still a (pun unavoidable) rapidly moving target, a target where this demo highlights both substantial advances and still as-yet unresolved serious shortcomings.
The advances mostly relate to the introduction of machine learning and 15TB of training data into the content production workflow to reduce a rendering job from 6 hours per 50 frames to 3 milliseconds per frame as detailed in this article:
https://www.globenewswire.com/news-release/2021/12/10/234977...
Returning for just a moment to the UE vs Unreal thing, those results were discussed in an article about a demo created using Ziva Dynamics's Real Time Trainer and Unreal Engine 4.26, but Ziva was subsequently acquired by Unity.
The discussion I'd be interested to see here (or somewhere else!) is about how ZRT compares with (or perhaps even fits into?) Unreal Engine's Metahuman workflow and resulting content creation and realism results.
Perhaps more importantly, how might the ML-driven capabilities of ZRT (will they still continue to be available under Unreal as well as Unity?) and ML-based impact upon realism be expected to manifest themselves
Here's a link to the ZRT 'preparation workflow', which a Z-brush user who was trialling the trainer setup says took them about an hour to produce a workable result:
https://drive.google.com/uc?export=download&id=15J6vX-6vU5EU...
Yes, but are there any (other?) "non-blockchains" that are better as distributed ledgers"?
I'm assuming here that you didn't count Google Sheets as being a Blockchain, but that you did count it to be (capable of being used as) a distributed ledger
I anticipate potential use-cases ('level/scene generation' in game content creation) where this actually turns out to be the most valuable aspect of the output. I can't imagine that it would be too much of a stretch to 'start with a photo' as a 'seed' and use it to create a 3D world. My only concern would be 'sameyness tendency', in other words, the problem would be that a variety of seed photos of similar kinds of scenes would end up creating worlds that were too similar to one another to make 'still photo to fly-through movie to navigable detailed 3D world' a sufficiently 'creative' source of sufficiently differentiated new game worlds (or of sufficiently differentiated new fly-through movies). I suspect this could all be fixed by 'differentiator algorithms' interfering with the key variables of the 'refinement' process, as well as broadening and continually adding to the range of movies in the training data.
Well, once you had developed a tool for automatically generating Domain Specific Languages (presumably based upon getting the tool to educate itself about the domain in question) you could try to get it to develop a language specific to the Blockchain domain (perhaps intending to come up with an alternative to Solidity?).
This is a very interesting claim!
Are you making this claim on a purely empirical basis, as in:
(1) "no AI has ever 'discovered' anything notably new/important/useful/interesting/valuable
or are you instead claiming/suspecting that:
(2) AI could not 'in principle' discover/generate anything falling into the positive categories above?
Yes, I think this kind of requirement would lead us to a very interesting specification exercise which would address questions like:
(1) what are the different use cases relevant to identifying 'as yet unaddressed' programming language design issues?
(2) what are the 'success metrics' of a new language design?
(3) what are the 'unresolved shortcomings' of existing languages?
(4) What are the issues related to 'non-human language design'?
This last question is kind of about the opposite to 'readability as we know it', where you could anticipate a language suited to creating non-human-intelligible code, which might require tools to translate it into human intelligible form, kind of like the assembly-language to higher-level language issue but kind of in reverse.