[x3d-public] Warning: controversial and disturbing
GPU Group
gpugroup at gmail.com
Tue Oct 3 07:38:13 PDT 2023
Could the avatars have Levels of Detail including motion, so the avatars
close to you would have full skin, skeleton and motion, and the ones
further away would be lower resolution, including lower resolution
streaming animation data? The server farm with the water consuming cooling
tower would respond to your location and send you just the resolution you
need.
On Tue, Oct 3, 2023 at 8:26 AM John Carlson <yottzumm at gmail.com> wrote:
> Good point!
>
> Meanwhile, 11GB of avatar data is filling up my disk. How many avatars
> are there in a concert?
>
> Think again!
>
> John
>
> On Tue, Oct 3, 2023 at 9:18 AM GPU Group <gpugroup at gmail.com> wrote:
>
>> The humanoid skin and skeleton could be sent once. The Motion data for
>> the humanoid would/could be streamed.
>>
>> On Tue, Oct 3, 2023 at 8:16 AM John Carlson <yottzumm at gmail.com> wrote:
>>
>>> We're talking a humanoid with 500,000 polygons, not background.
>>>
>>> Try again!
>>>
>>> JOhn
>>>
>>> On Tue, Oct 3, 2023 at 9:02 AM GPU Group <gpugroup at gmail.com> wrote:
>>>
>>>> Could a server farm with water-consuming cooling towers render
>>>> background cube map by tile, and send that plus static 3D geometry once by
>>>> tile (say a few city blocks, like Cesium tiles), and then a smaller amount
>>>> of streaming animation for local sound, characters and mechanical
>>>> animation? A hybrid system?
>>>>
>>>> On Mon, Oct 2, 2023 at 9:53 PM John Carlson <yottzumm at gmail.com> wrote:
>>>>
>>>>> Streaming XML validation (answers anyone?)
>>>>>
>>>>>
>>>>> https://stackoverflow.com/questions/11776056/how-to-validate-large-xml-streams-in-a-way-that-it-creates-chunk-of-stream-read
>>>>>
>>>>> https://www.di.ens.fr/~segoufin/Papers/Mypapers/streaming-pods.pdf
>>>>>
>>>>>
>>>>> https://stackoverflow.com/questions/66003045/streaming-xml-schema-validation-using-xsd-files-in-databricks
>>>>>
>>>>> Streaming JSON validation:
>>>>>
>>>>> https://arxiv.org/abs/2211.08891
>>>>>
>>>>> https://github.com/awwright/jsonschemaparse
>>>>>
>>>>> When will we see streaming parsers and validators on the web and in
>>>>> Saxon-HE?
>>>>>
>>>>> Have you tried converting an 10GB XML file to Python? Or convert a
>>>>> large JSON file to Java? (Hint, X3DJSONLD requires Ajv, Node.js or an
>>>>> ordinary web JSON parser)
>>>>>
>>>>> Anyone?
>>>>>
>>>>> No one?
>>>>>
>>>>> Am I alone?
>>>>>
>>>>> John
>>>>>
>>>>> On Mon, Oct 2, 2023 at 10:26 PM John Carlson <yottzumm at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Document model seen as fundamentally limited. The Metaverse is too
>>>>>> big to fit in a Document. Request/Response of HTTP/HTTPS seen as flawed,
>>>>>> multi-request/multi-response (DIS?) preferred.
>>>>>>
>>>>>> We should move post-haste to solutions like DIS, VRML, SAI, Streaming
>>>>>> API for XML (StAX), and streaming JSON parsers, and streaming validators.
>>>>>>
>>>>>> Things like DOM are unworkable for large streaming assets. Imagine a
>>>>>> live feed with real-time animation over a period of hours. A concert, for
>>>>>> example. Imagine several BVH files being streamed live—you’ve got to drop
>>>>>> some portion or compress the file.
>>>>>>
>>>>>> Think of streaming solutions like JavaScript and Python. Not
>>>>>> something that fits in a single file, or outputs a single document, but
>>>>>> something that consumes or emits a stream. SAI is the right approach, but
>>>>>> call it the Streaming Access Interface.
>>>>>>
>>>>>> Ever have a JSON file that was too large to parse? Many JSON parsers
>>>>>> assume that they can pass back a single object. What if that object is too
>>>>>> big for memory? What happens? We should focus on Streaming parsers for
>>>>>> JSON and XML. Don’t worry about duplicating keys!
>>>>>>
>>>>>> Current “create only” solutions do not fit the real world. Updates
>>>>>> and deletes with SAI and DIS should be considered. Reduce, Reuse,
>>>>>> Recycle. Systems that do not provide update and delete are flawed. No
>>>>>> plastics filling up my SSD, please!
>>>>>>
>>>>>> Yes, we will still support non-streaming technology, with a limited
>>>>>> file size. I recommend specifying a Content-Length on limited sized files.
>>>>>>
>>>>>> Maybe I should get a faster bus/disk?
>>>>>>
>>>>>> Is MSF listening, or are they doomed too?
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231003/3cdc1e87/attachment.html>
More information about the x3d-public
mailing list