|Search this Thread|
|16th Apr 2015, 11:24 AM||Understanding geostates #1|
This is a kind of request, but it's for learning purposes, so please hear me out.
I want to give myself one last chance to understand how geostates are defined.
It seems very complicated to me so I thought that maybe using a small and very simple example
can help me to figure out how they work. So I made a very simple mesh with one little cube inside
a bigger cube. What I'd like to ask with this post is someone to take this mesh and define 2 geostates:
one for the whole mesh and one with only the internal smaller cube.
Why I don't do that myself? I can't use TSRW and I never managed to make the Blender plugin work
(I can bake textures and create a shadow mesh with it, but not managing geostates sadly).
I'm not that masochistic, if I could handle geostates more easily I'd do it.
Once I see (with S3PE) how geostates are handled for a mesh so simple maybe I can understand how
they work and be able to define them directly with (as crazy as that may sound). It seems very
weird to me that they are defined with only 4 parameters (plus the name):
Probably there is more to it and I just don't see it, I can't really understand how vertices/faces are selected/ordered.
Maybe TSRW can't just open a mesh without an actual object, if so let me know and I'll provide a full fledged object
(of if you know about an existing simple object that uses geostates let me know).
|17th Apr 2015, 3:26 AM||#2|
Join Date: Aug 2013
The geostates are effectively different groups of one mesh. So for example we can look at a bookcase bookshelfModernHigh1X1 which has at the high level of detail
Mesh group 0
1262 vertices, 768 faces
and two geostates
648 vertices, 440 faces
index buffer offset 984
vertexbuffer offset 614
vertex count = 648
1262 vertices, 548 faces
index buffer offset 2304
vertexbuffer offset 0
vertex count = 1262
If we use to export the MLOD group 00000000 as a .s3ac files, we can see the right amount of vertex and face data within the VBUF and the IBUF sections in the .s3asg, but there is no data for the geostates, so we need to infer it.
For the first geostate if we start at vertex 614, and read 648 vertices, that should give us all the vertices used by the geostate.
If we start at face 328 (or point 984) and read 440 faces (1320 points), that should give us all the faces.
For the second geostate it looks like we read the faces backwards, since 2304 points would put us at the end of the IBUF.
Hope this helps
PS I am not sure what to do with your .model file to get it into TSRW
|17th Apr 2015, 1:05 PM||#3|
Thank you, I appreciate your help. I'm starting to think that I'm hopeless, my little brain struggles
with these concepts (even with simpler things like regular meshing, UV mapping, etc).
# The geostates are effectively different groups of one mesh
To avoid confusion, you are using the term "group" in a general way and not like group00, group01, right?
Or, in other words, you mean that it's an additional grouping inside a group of a mesh?
So vertices and primitives (aka faces, aka triangles, if I get this right) have to be in a specific order to be able
to choose an index/offset and a count to select a specific portion of the mesh? This means that the mesh itself
must be built/designed with that in mind? Do tools that edit geostates "re-number"/"re-sort" them (vertices and
faces) internally somehow? I mean, do they modify the mesh itself in order to be able to create/define sub-sets?
That would mess the UV mapping too I guess. I'm so confused.
Or maybe is only showing a little part of what constitutes/defines geostates, other info/data are in a binary
format not made human readable by "Grid" or by the preview window?
Can TSRW open a .package file? And with that I mean an OBJD in a package file?
So, I have 2 cubes, one inside the other, it's 16 vertices and 24 triangles/faces. Should be very simple to study this one.
But when I export it with MIlkShape I get the message "50 vertices split" and it ends up with 66 vertices. <auto-censored>!
Why? Is that normal? Gee, if I don't even understand this then I guess I have no hope to understand geostates.
Can that have something to do with assigning vertices to the joint?
Anyway, let's try and see what happens. I've cloned another object without changing the UV mapping or the texture
(EDIT: nor the footprint and the boundingbox on the VPXY), but that shouldn't matter for the purpose of the experiment.
If you can define 2 geostates like I asked in the OP, I'll see if I can understand something more about it thanks to the simplicity of this mesh.
|17th Apr 2015, 5:52 PM||#4|
Join Date: Aug 2013
Yes this is an additional grouping inside Mesh or whatever, which is in turn inside an MLOD chunk.
Looking at the bookshelf example again, there are really three states for the mesh, since the default full bookshelf uses no geostate, and uses all 768 faces.
Then we have Geostate 0x8A6C4E39 with 548 faces whcih corresponds to a half-full bookshelf, and Geostate 0x4CF9B596 with 440 faces that is nearly empty.
So I think that the mesh data in the IBUF needs to be structured.
I have not looked closely enough at the point by point layout, but it is certainly possible to re-slice Geostate 0x4CF9B596 in TSRW by telling it to use a different number of faces and a different index buffer offset. I will try to make some illustrations this weekend.
The geostate information in Preview window is complete. The vertex and face data is in other chunks, though, and doesn't show up in the Preview window, hence it's much easier to look at by exporting a .s3asc.
TSRW will open a package file, but I don't know if it will read an OBJD. Something else to follow-up this weekend.
|19th Apr 2015, 7:28 PM||#5|
Join Date: Aug 2013
I have made a quick edit of the GeoStatesCaseStudy.package file to split the two cubes into separate geostates.
I got the package file into TSRW, although it complained about a missing LITE resource, but I didn't see a way to add the geostates, so I went back to and did it there in Grid.
I named them
 : 0x4CF9B596
 : 0xBC2C0BE9
and set the face counts to 12, with point offsets of 0 and 36.
The vertex ranges I left at offset 0, count 66.
TSRW doesn't seem to care what the geostate vertex count is, as long as it is at least 1 (but it doesn't draw the geostate if the vertex count is zero). The game might not be so forgiving.
This creates two geostates, one for each cube.
|19th Apr 2015, 7:38 PM||#6|
Join Date: Aug 2013
It is important to make sure the geostate point offset is a multiple of three, otherwise you will get a mess, as shown below:
In the first image the point offset is 99 so the mesh faces are drawn as intended.
In the second image the point offset is 100, so the faces are drawn using two points from one triangle primitive and one point from the next.
|19th Apr 2015, 8:57 PM||#7|
Sorry about the lack of the LITE resource, the object I cloned didn't have that
(it didn't really need it so I deleted it directly, not sure if it's a good thing).
TSRW, on the other hand, fu**ed the Name Mapping and STBLs.
Or I have to blame you for that? ;P
I'm guessing "base" (0x4CF9B596) is the smaller cube, because it has no StartIndex/offset
(and was the cube that I drow first with MilkShape). EDIT: yep, confirmed.
You set 12 (0xC) as PrimitiveCount because a cube has 6 faces but MilkShape (or more likely just the
format used by TS3) handles faces with triangles, so it takes 2 triangles to make a face (6*2=12). Right?
Judging by MinVertexIndex and VertexCount, vertices are not taken into consideration in this case
(both geostates "use" them all). Is there an explanation for this?
How you calculated/obtained 36 (0x24) as StartIndex/offset? That is the offset of what? The faces?
EDIT: oh, point offset. Mmmm... what does that mean? Is that about vertices?
And how you get that specific number? Maybe 12*3 (12 being the number of faces
and 3 being the vertices of a single triangle)?
Anyway, I'm writing a script to test the geostates... wait for it...
It works!!! I love you with all my little dark heart!
[if you want to try it in game, the object is in the Buy Catalog under ByFunction/Appliances/Misc]
So, how can I/we generalize this? I guess this worked flawlessly also (if not mostly)
because the vertices and the faces were sorted in a very precise order.
But what about more complex shapes where following a certain order when drawing
the mesh is not so straightforward? Or what about existing meshes, like foods?
Thanks a lot for your help!
|19th Apr 2015, 10:25 PM||#8|
Join Date: Aug 2013
All those blank STBLs are courtesy of TSRW, which also exported the file as a Sims3Pack that I had to extract.
You can do more complicated visual effects by having several meshes in one chunk that all use geostates with the same name, although I still haven't worked out all the details
The EP9LimitedSET party statue has MLOD : 01D10F34-00000000-0000000000DCAE9D Mesh Count = 10 to allow for several different effects.
Most meshes have six of the following GeometryStates with face count = 0 and vertex count = 0
So if you select geostate 0xA9629C93 masquerade, all the meshes which have that geostate are invisible, but the real masquerade mesh is not.
See below for the different options: