[x3d-public] Warning: controversial and disturbing

[GPU Group]

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/d55dd2a8/attachment.html>