Godot: Write a specification for .tscn

[ghost]

On godotengine/collada-exporter#43 recently but in other issues as well the role of Collada in the Godot pipeline was discussed, and some people (like @reduz) expressed the possibility that .tscn is used directly instead of Collada, considering Blender supports PBR in the Cycles renderer, which is incompatible with the Blender Internal renderer which is used for exporting right now (like @set-killer pointed out).

I think that a better 3D pipeline is necessary for Godot 3.0 to become popular as a 3D engine. Not saying Collada support should be dropped but just looking at some facts:

1. The latest version of Collada was released in August 2008
2. Collada is (was?) developed by a committee of big names like Sony, so contributing to it is not easy
3. Collada is not that popular, even among FLOSS game engines
4. The Blender devs haven't really said if they want to merge BCE or not, but from what I've understood they are on the fence about it because it doesn't have an importer

Exporting to .tscn might be a better idea but the problem is that it is not really an open standard, since there is no formal specification out there and it's directly tied to Godot's implementation, while Collada is, so data between other engines and 3D programs can easily be exchanged (ideally).

So I propose a specification for .tscn is written, so that all coders who wish to do so can easily implement .tscn importers and exporters without having to crawl into Godot's source.

It would be bad if Godot's excellent 3D capabilities were held back by a third-party format, and it would be even worse if proprietary formats like FBX were adopted, so I say that since .tscn already exists and that it is fine-tuned for being used with Godot, some work should be done to make sure a 3D pipeline can be built around it.

[Ace-Dragon]

If Godot did have its own 3D format, I doubt it would be .tscn.

The reason why is because it encompasses far more than just 3D information, but also everything related to scenes in Godot including 2D ones (and there's no issue importing 2D content).

In short, the .tscn format is just too expansive (Collada and friends meanwhile are mainly just formats for 3D content).

[reduz]

A few bits of clarification..

1) Blenders decision to go with OpenCollada was retarded, writing a hand-made Collada parser and exporter is orders of magnitude simpler. The XML file format itself is much simpler than OpenCollada. I warned them about this a decade ago but they did not listen.

2) No matter how you look at it, it will be much simpler to write a direct .tscn exporter, so we can keep a lot more information.

3) There is not really anything meaningful in the .tscn format. Its just nodes and resources serialized and what you see in there is their properties. Best is probably to export some scene and see how it looks in text to understand it.

[punto-]

Also keep in mind that the industry tends to use Maya more than Blender, so
we still need a way to import from there that gives us all the data we need.

On 16 November 2016 at 00:38, Juan Linietsky [email protected]
wrote:

A few bits of clarification..

1) Blenders decision to go with OpenCollada was retarded, writing a
hand-made Collada parser and exporter is orders of magnitude simpler. The
XML file format itself is much simpler than OpenCollada. I warned them
about this a decade ago but they did not listen.

2) No matter how you look at it, it will be much simpler to write a direct
.tscn exporter, so we can keep a lot more information.

3) There is not really anything meaningful in the .tscn format. Its just
nodes and resources serialized and what you see in there is their
properties. Best is probably to export some scene and see how it looks in
text to understand it.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7102#issuecomment-260845027,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGVmPTyhLzW_bIr1u9VzJ-0RD_9rXVZgks5q-nqbgaJpZM4KwbtK
.

[ghost]

I warned them about this a decade ago

@reduz Still, after a decade, it's not sure they will merge BCE, and with Cycles the Collada situation is getting even worse.

I am sure that eventually they will replace OpenCollada with a Python addon, they said as much in their blog. They problem is when: who can ship first, the Godot team with a .tcsn exporter or them with a brand-new Collada exporter+importer? I would say the former, considering that I'm not sure they started working on it (and it doesn't seem they will necessarily pick up BCE).

3) There is not really anything meaningful in the .tscn format. Its just nodes and resources serialized and what you see in there is their properties. Best is probably to export some scene and see how it looks in text to understand it.

There is nothing meaningful in .JSON either, but it does have a specification. Documentation here would be useful for contributors. Even just an index of all nodes and resources would be very useful.

[bojidar-bg]

@paper-pauper

Even just an index of all nodes and resources would be very useful.

I think this counts as a list of "Nodes and Resources", no? Docs/Classes Reference

[ghost]

@bojidar-bg Thanks and I guess it does but I don't think it makes it any easier to help people write exporters from 3D programs to .tscn :confused:

[punto-]

Definitely there's some basic stuff to document, like how to format values
of each data type, and the basic structure of the file, but the detail of
what each property means probably goes in the nodes documentation

On 16 November 2016 at 08:12, paper-pauper [email protected] wrote:

@bojidar-bg https://github.com/bojidar-bg Thanks and I guess it does
but I don't think it makes it any easier to help people write exporters
from 3D programs to .tscn 😕

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7102#issuecomment-260919628,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGVmPZUnHABSDOhoQnAyHLhVteP-NnDFks5q-uUogaJpZM4KwbtK
.

[dodgyville]

Hi, what are the rules for the serialisation? It doesn't look like xml or json. Maybe a little bit yaml?

[vnen]

It is a custom format, loosely based on INI. The text format itself is basically on scene_format_text.cpp but the serialization process is done by the variant parser.

[dodgyville]

Thanks!

Is it possible to get godot to indent the multiline values in a tscn by default?

tracks/0/keys = {
    "times": PoolRealArray( 0, 1),
    "transitions": PoolRealArray( 1, 1),
    "update": 0,
    "values": [ Color( 0.45112, 0.09609, 0.18779, 1 ), Color( 0.55547, 0.0429, 0.18366, 1 ) ]
    }

instead of

tracks/0/keys = {
"times": PoolRealArray( 0, 1),
"transitions": PoolRealArray( 1, 1),
"update": 0,
"values": [ Color( 0.45112, 0.09609, 0.18779, 1 ), Color( 0.55547, 0.0429, 0.18366, 1 ) ]
}

That would make it easier to use 3rd party modules like python's configparser to read them.

[dodgyville]

To indent I think it might be as simple as this but I'm not confident with the godot code base.

diff --git a/core/variant_parser.cpp b/core/variant_parser.cpp
index 54edb0234..6771c6fa5 100644
--- a/core/variant_parser.cpp
+++ b/core/variant_parser.cpp
@@ -1784,7 +1784,7 @@ Error VariantWriter::write(const Variant &p_variant, StoreStringFunc p_store_str
            dict.get_key_list(&keys);
            keys.sort();

-           p_store_string_func(p_store_string_ud, "{\n");
+           p_store_string_func(p_store_string_ud, "{\n    ");
            for (List<Variant>::Element *E = keys.front(); E; E = E->next()) {

                /*
@@ -1795,10 +1795,10 @@ Error VariantWriter::write(const Variant &p_variant, StoreStringFunc p_store_str
                p_store_string_func(p_store_string_ud, ": ");
                write(dict[E->get()], p_store_string_func, p_store_string_ud, p_encode_res_func, p_encode_res_ud);
                if (E->next())
-                   p_store_string_func(p_store_string_ud, ",\n");
+                   p_store_string_func(p_store_string_ud, ",\n    ");
            }

-           p_store_string_func(p_store_string_ud, "\n}");
+           p_store_string_func(p_store_string_ud, "\n    }");

        } break;
        case Variant::ARRAY: {

[viktor-ferenczi]

I think using yaml for all textual project files (tscn, tres, ...) would be ideal. Conversion from existing INI based format could be done as a single migration / project conversion step.

Advantages:

• Readable
• Source control friendly
• Supports atomic data types for values (not everything is text)
• Good libraries are available for all major programming languages (external tooling could use any language suitable for the task matching the existing libraries)

Considerations for maximum source control friendly behavior (minimal diffs):

• Yaml serialization should be one field per line with minimal (like 2 spaces) indentation
• Keys should be sorted on serialization
• Editor and tools either need to write all keys or avoid making unnecessary changes (omitting defaults would also be an option, but the problem is what happens if the default changes between releases)

[Calinou]

The format is now documented in the TSCN file format documentation page, closing. (For the record, .escn and .tres files follow the same syntax.)