-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
more than one texture per surface? #3
Comments
@kenohori @clausnagel "material": {
"irradiation": {
"values": [[0, 0, null, null, 1, 1]]
},
"irradiation-2": {
"values": [[2, 2, null, null, 1, 1]]
}
} and the values are just the references to the materials in the "texture": {
"winter-textures": {
"values": [
[ [[0, 10, 23, 22, 21]], [[null]], [[null]], [[0, 1, 2, 6, 5]], [[0, 2, 3, 7, 6]], [[0, 3, 0, 4, 7]] ],
[ [[null]], [[null]], [[0, 0, 1, 5, 4]], [[0, 1, 2, 6, 5]] ]
]
},
"summer-textures": {
"values": [
[ [[1, 7, 3, 2, 1]], [[null]], [[null]], [[1, 1, 2, 6, 5]], [[1, 2, 3, 7, 6]], [[1, 3, 0, 4, 7]] ],
[ [[null]], [[null]], [[1, 0, 1, 5, 4]], [[1, 1, 2, 6, 5]] ]
]
}
} And to ensure that a viewer picks the right theme when >1, one can define the following in the "appearance": {
"default-theme-texture": "summer-textures",
"default-theme-material": "irradiation",
"vertices-texture": [ If not define then the viewer just picks whatever it wants. |
Sorry for re-opening. The My suggestion is to simply use
Just to illustrate a possible issue with the current |
I have been watching these discussion roll by, and I am no expert in the development of such formats. However, maybe I can just pitch in here. I would assume that models will often have many surfaces with no texture. For example, with irradiation, you may only want these textures on the glazed areas. In such cases, endless lists of null values might not be desirable. An alternative may be to explicitly list the surface indices for each set of values rather than relying on the array position. |
I don't think [null] or [[null]] make much sense. Since those arrays don't have the number of vertices as their corresponding ones in the geometry object, a developer cannot assume that they have the same structure. So, I'd second @clausnagel's suggestion. Going back to a discussion with @hugoledoux some time ago, maybe we can take it one step further and say that arrays consisting solely of null objects (e.g. [null, null, null] or [[null], [null]]) can always be flattened to null. |
Using This is one idea Ken and I discussed a few months ago, but we left it aside because the implementation is more complex. But perhaps time to bring it back now. It would solve most of the issues I reckon (@phtj: I dislike have new IDs to refer to the primitives... sorry) and have more compact files. So the idea is that for
The same applies to null and for semantics with Semantic objects. I've built in c++ a quick demo with a snippet showing how to extract the material/texture/semantics for a single geometry: https://github.com/tudelft3d/cityjson/blob/hierarchical-arrays/hierarchy-tests/main.cpp Everything working. @kenohori tried for null with Ruby and it's also super simple. What do you think? |
If I get your hierarchical idea right, then wouldn't it de-facto just make sense for For example, isn't it rather unlikely that all surfaces of a For So if my understanding is correct, then perhaps adding one additional |
Btw, I support the proposal of @kenohori to flatten arrays containing solely |
I'm also in favour of the null flattening, but it breaks the schema since the depth of the arrays is prescribed for the different Primitives... One solution is to modify the schema just so that it's only a JSON object, and write code to to further validate (cityjson-valschema does this to some extent already). Or perhaps there's another way to define this in a schema, but I am not aware and would have to investigate this further. Also, a few points from the discussions above:
So yeah, let's do a poll I guess! |
No opinions so far? Well, here is my two cents: I was not aware that using I wonder about the proposed change to the Regarding Gson: The idea is that you define a Java class which represents a Json object and whose fields represent the properties of this object. The serialization and deserialization is then done automatically, so you do not have to fiddle around with Json elements. But this requries unique data types. As mentioned above, you can also write custom code in Gson like in your example in order to handle non-default cases. Btw, I have completed a first CityGML-to-CityJSON support in citygml4j (against the current v0.3 schema). It should (hopefully) work for all sorts of building representations in CityGML. So I am happy to produce example CityJSON files which might be helpful in studying the layout of CityJSON datasets - just let me know. The changes are not yet on GitHub. I first have to implement a clean API and also want to work on CityJSON-to-CityGML. |
We were busy thinking about and testing what flattening means in terms of implementation in different programming languages. Putting implementation first might be a philosophical difference with respect to CityGML 😉. Languages like Ruby and Swift are a piece of cake. There are conditional evaluations that can be called even if something is null (?. and &. respectively). With flattened values, we do need a series of ifs at every level, but the code is relatively easy in all languages we tested. In theory, any language with type introspection (or a library that provides it) should work. Hugo and I also looked into how to redefine the schema to allow for arrays of varying depth. I think it should work by defining a series of custom types at every level of the hierarchy. I'm in favour of this, but it does make the schema more complex... Regarding the Gson serialisation, I reckon you could implement a custom (de)serialiser for the array types. Something like this: Personally, if the implementation is not too messy, I'm in favour of flattening everything (nulls and values). |
@kenohori Thanks for your response. Don't get me wrong - I am not complaining about coding complexity. In fact, I have already implemented the flattened array approach in my CityJSON support in parallel to the v0.3 schema. Your link to the custom Json adapters is exactly what I meant with custom code in my previous post. |
It seems that we decide here, and for me either way is good. It seems for you too Claus, and Ken too. If we're ambivalent, I'd then go for the flattened array approach because:
If you approve this (with a thumbs up) then I'll figure something out for the schema (or @kenohori will, I recall you promising :)). And it's fantastic if citygml4j works, I do want some files yes, mine are all rather hacked. |
with v0.5 the Semantic Surfaces are handled "better", and there is no need for hierarchical arrays. And |
@jstoter gave the noise modelling example with different scenarios/params having diff results which become textures of the walls of buildings.
The text was updated successfully, but these errors were encountered: