Welcome to
Mod The Sims
Online: 3338
News:
Have an account? Sign in:
pass:
If you don't have an account, why not sign up now? It's free!
Other sites: SimsWiki
Reply  Replies: 7 (Who?), Viewed: 4642 times.
Search this Thread
Old 16th Apr 2015, 11:24 AM DefaultUnderstanding geostates #1
Arsil
Original Poster

Inventor

Join Date: Jul 2014
Posts: 999
Thanks: 15809 in 73 Posts
15 Achievements


Hello ^^
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 S3PE (as crazy as that may sound). It seems very
weird to me that they are defined with only 4 parameters (plus the name):
- StartIndex
- MinVertexIndex
- VertexCount
- PrimitiveCount
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).
Download - please read all instructions before downloading any files!
File Type: zip GeoStatesCaseStudy.model.zip (1.1 KB, 16 downloads) - View custom content
Last edited by Arsil : 16th Apr 2015 at 11:37 AM.
Old 17th Apr 2015, 3:26 AM #2
peter9g
Test Subject

Join Date: Aug 2013
Posts: 17


Hi Arsil

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

Geostate 0x4CF9B596
648 vertices, 440 faces
index buffer offset 984
vertexbuffer offset 614
vertex count = 648

and
Geostate 0x8A6C4E39
1262 vertices, 548 faces
index buffer offset 2304
vertexbuffer offset 0
vertex count = 1262

If we use S3PE 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

Peter

PS I am not sure what to do with your .model file to get it into TSRW
Old 17th Apr 2015, 1:05 PM #3
Arsil
Original Poster

Inventor

Join Date: Jul 2014
Posts: 999
Thanks: 15809 in 73 Posts
15 Achievements


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 S3PE 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.
Download - please read all instructions before downloading any files!
File Type: zip Arsil_GeoStatesCaseStudy.package.zip (2.8 KB, 12 downloads) - View custom content
Last edited by Arsil : 17th Apr 2015 at 7:17 PM.
Old 17th Apr 2015, 5:52 PM #4
peter9g
Test Subject

Join Date: Aug 2013
Posts: 17


Yes this is an additional grouping inside Mesh[0] 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 S3PE 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.

Peter
Old 19th Apr 2015, 7:28 PM #5
peter9g
Test Subject

Join Date: Aug 2013
Posts: 17


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 S3PE and did it there in Grid.
I named them
[0] : 0x4CF9B596
[1] : 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.
Screenshots
Click image for larger version

Name:  wireframe cubes.png
Views: 0
Size:  9.1 KB  
Download - please read all instructions before downloading any files!
File Type: zip New_OBJD_Project_01.zip (5.0 KB, 10 downloads) - View custom content
Description: Modified GeoStatesCaseStudy.package with two geostates
Old 19th Apr 2015, 7:38 PM #6
peter9g
Test Subject

Join Date: Aug 2013
Posts: 17


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.
Screenshots
Click image for larger version

Name:  geostates F653-099.png
Views: 0
Size:  93.5 KB   Click image for larger version

Name:  geostates F653-100.png
Views: 0
Size:  87.2 KB  
Old 19th Apr 2015, 8:57 PM #7
Arsil
Original Poster

Inventor

Join Date: Jul 2014
Posts: 999
Thanks: 15809 in 73 Posts
15 Achievements


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

Code:

      --- GeometryStateList: GeometryStates (0x2) ---

      --- GeometryStates[0] ---
         Name: 0x4CF9B596  ---> "base"
         StartIndex: 0x00000000
         MinVertexIndex: 0x00000000
         VertexCount: 0x00000042 (decimal 66, total # of vertices)
         PrimitiveCount: 0x0000000C (decimal 12)

      --- GeometryStates[1] ---
         Name: 0xBC2C0BE9 ---> "test"
         StartIndex: 0x00000024 (decimal 36) Where this comes from???
         MinVertexIndex: 0x00000000
         VertexCount: 0x00000042 (decimal 66)
         PrimitiveCount: 0x0000000C (decimal 12)


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!
Screenshots
Click image for larger version

Name:  Screenshot.jpg
Views: 0
Size:  171.9 KB  
Download - please read all instructions before downloading any files!
File Type: zip GeoStatesCaseStudy_With2GeoStates.package.zip (7.9 KB, 8 downloads) - View custom content
Last edited by Arsil : 19th Apr 2015 at 9:09 PM.
Old 19th Apr 2015, 10:25 PM #8
peter9g
Test Subject

Join Date: Aug 2013
Posts: 17


All those blank STBLs are courtesy of TSRW, which also exported the file as a Sims3Pack that I had to extract.

Quote:
But what about more complex shapes where following a certain order when drawing
the mesh is not so straightforward?


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
--------------------
0xFB3F0160 formal
0xA9629C93 masquerade
0x69BE305F sleepwear
0x304EFC08 swimwear
0xC845B606 toga
0x2EA8FB98 default
0x20B5041A casual

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:
Screenshots
Click image for larger version

Name:  casual.png
Views: 0
Size:  43.5 KB   Click image for larger version

Name:  default.png
Views: 0
Size:  37.8 KB   Click image for larger version

Name:  formal.png
Views: 0
Size:  43.8 KB   Click image for larger version

Name:  masquerade.png
Views: 0
Size:  45.0 KB   Click image for larger version

Name:  sleepwear.png
Views: 0
Size:  46.7 KB   Click image for larger version

Name:  swimwear.png
Views: 0
Size:  45.7 KB   Click image for larger version

Name:  toga.png
Views: 0
Size:  44.8 KB  
Reply


Section jump:


Powered by MariaDB Some icons by http://dryicons.com.