[Pkg-pascal-devel] Castle Game Engine 7.0-alpha.2, view3dscene 4.2.0 releases

[Michalis Kamburelis]

In this case, the VRML file
/usr/share/doc/whitedune-docs/docs/x3d/CADGeometryPROTO.wrl is really
invalid.

While I can imagine how to "tolerate" such files, but it would be
quite a hack in CGE (tovrmlx3d just uses Castle Game Engine to read
X3D). We would effectively guess too much "what was the intention of
the author of this VRML file". I would need to encode that, where a
single string is expected in VRML, we allow a sequence of "string +
(identifier + string)*" and we just glue them all together, assuming
that it's actually one long string but someone forgot backslashes.
That's too much guessing, and too big hack, just to support a single
invalid file :)

I wanted to look at what others do:

- FreeWRL: https://freewrl.sourceforge.io/ (4.0) also fails to read
it. Adding backslashes, as I suggested above, makes FreeWRL also read
it OK. So basically FreeWRL behaves the same as
view3dscene/tovrmlx3d/CGE in this case. And it's a completely
independent codebase to read VRML/X3D files.

- I wanted to test whitedune itself, alas it fails for me with a
SEGFAULT now (just running it without any parameters makes a
SEGFAULT). Tested on Debian (whitedune 0.30.10-2.2) and another
machine with Ubuntu (whitedune 0.30.10-2.2build1).

The part of the CADGeometryPROTO.wrl file that misses backslashes
contains a shader code inside a VRML string. While this is a comment
for shader (GLSL), but first the VRML browser must read the string
with shader code, and the "Script.url" must contain something that can
be parsed.

All in all, we cannot easily ignore this problem on tovrmlx3d side --
it would be a too big hack, just for this file. And I have yet to see
any VRML browser that actually opens this file :)

My suggestion would be to:

- Report this to whitedune-docs, as error in
/usr/share/doc/whitedune-docs/docs/x3d/CADGeometryPROTO.wrl.gz

- While you're at this, check can you run whitedune at all. If it
SEGFAULTs for others, then this is likely even more critical bug we
should submit to whitedune package.

- In view3dscene: either stop testing on whitedune-docs, or at least
omit this particular faulty file CADGeometryPROTO.wrl.gz .

- If you're looking for files to test, we maintain a big repository of
test models on https://github.com/castle-engine/demo-models . All on
open-source licenses. Though I understand you would want something
that is already part of Debian.

Regards,
Michalis


wt., 25 paź 2022 o 20:54 Paul Gevers <elbrus at debian.org> napisał(a):
>
> Hi
>
> On 25-10-2022 18:25, Abou Al Montacir wrote:
> > Gi Michalis,
> >
> > On Mon, 2022-10-17 at 13:36 +0200, Michalis Kamburelis wrote:
> >> The "true" above should be \"true\" , i.e. you need to escape the
> >> double quotes with backslashes. Otherwise this is not valid VRML file.
> >>
> >> Once you do this, there's a similar case with "malloc" -> \"malloc\"
> >> at line 201.
> >>
> >> And again "true" -> \"true\" at line 335.
> >>
> >> And again "malloc" -> \"malloc\" at line 382 (this look this block was
> >> copy-pasted).
> >>
> >> After fixing 1 and 2, the output of "tovrmlx3d
> >> ./CADGeometryPROTO.wrl..." is clean.
> > While I don't understand why we need to escape quotes inside a comment
> > line (but I don't now VTML at all), I fear this will not be possible as
> > I can't change files belonging to other packages.
> >
> > Of course I can always open a ticket against whitedune-docs package and
> > wait for it to be fixed, but you know sometimes this takes ages.
>
> Or we disable (that part of) the test suite? Or we search for a
> different source of 3D files. I mean, we're not bound to whitedune-docs
> in any way.
>
> > So if there is a patch to make tovrmlx3d support this or at least ignore
> > it silently, we may be able to get view3dscene packaged.
>
> If Michalis says it's invalid VRML, I can see why he wouldn't want that.
> If it's possible to clearly identify this as "user mistakes" than it
> could be ignored, but I would expect it has to be escaped for a reason.
> On the other hand, what they often say about internet daemons: be strict
> in what you send, be forgiving in what you receive (concerning
> protocol). I guess the same potentially could apply here.
>
> Paul
> _______________________________________________
> Pkg-pascal-devel mailing list
> Pkg-pascal-devel at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel