XeNTaX

gtasamimi wrote:hmm...Don't work New Version too
Please release a version of bugs fixed!
I and some people can't use Forza Studio
and we want to use Forza Studio ><
Thanks

It's either yu or your PC.
We can use FS without any error.

gtasamimi wrote:hmm...Don't work New Version too
Please release a version of bugs fixed!
I and some people can't use Forza Studio
and we want to use Forza Studio ><
Thanks

It's definitely something your end, there is nothing wrong with forza studio. it is working fine and as expected, complete with mtl files being created. If it was so full of bugs, nobody would be able to use it

is there a way to convert the mesh to editable poly without using the open collada and 3dsimed?

Because i'm using max 2011 and open collada doesn't go with max 2011.

And the use of the textures is a still a bit confusing to me, yes i know how to use textures but the material editor in max is full and i'm still going by trial and error.

Just apply an editable poly modifier rather than converting it.
Can we please keep all discussion of "bring it to this app, then export it to this app, then import it to this app" out of here?
Remember, this topic is for fundamental research of the .carbin file format.

I think getting a piece of useable LOD0 mesh actually is topic-related.

maybe try ZModeler2->GTA4 WFT->MAX GTA4 import filter.

in GTA4, every mesh looks fine for me.

XSB wrote:I think getting a piece of useable LOD0 mesh actually is topic-related.

maybe try ZModeler2->GTA4 WFT->MAX GTA4 import filter.

in GTA4, every mesh looks fine for me.

We already can use LOD0. its only people,that insist on using max ( possibly other autodesk products ) that have to do this editable poly mesh business. the models load in perfectly fine in most other apps. and you can edit them right away without having to do anything special to them.
So as veegie said can we keep " app specific issues" to other threads and keep this one for just the carbin files..

But the problems are only with Forza 3 Files... copy?

So here is the right place to discuss these problems because it's researching Forza 3 files too

Since I have never seen this kind of deformation in 3D Studio MAX besides Forza's meshes, I think it should somehow be related to... hmm. I don't really know. Do you think it might be related to Forza3 meshes?

And, since the thread was created to export Forza3 meshes, I think this should probably be the right place to discuss the methods of working with LOD0 forza meshes.

And, since the LOD0 models contain some tiny chamfers, so tiny, that most 3D app recognises those polies as simple lines, that probably cause the error mentioned, and probably a member could find a script or something to fix it

Well i've been exploring a bit.

The max issue ain't normals and ain't smoothing...

The wierd thing is when i run optimize on the editable poly mesh most of that reflection issue just dissapears. gonna look more into it.

BTW how do I rip the cars from the 2 DVD. and also DLC would be nice.

3n1g wrote: BTW how do I rip the cars from the 2 DVD. and also DLC would be nice.

Use wxPirs

XSB wrote:Since I have never seen this kind of deformation in 3D Studio MAX besides Forza's meshes, I think it should somehow be related to... hmm. I don't really know. Do you think it might be related to Forza3 meshes?

And, since the thread was created to export Forza3 meshes, I think this should probably be the right place to discuss the methods of working with LOD0 forza meshes.

And, since the LOD0 models contain some tiny chamfers, so tiny, that most 3D app recognizes those polys as simple lines, that probably cause the error mentioned, and probably a member could find a script or something to fix it

Furthermore, if they were using max to model the originals (as shown from an earlier post), why does max have issues? I was looking at the LOD0_cockpit for the Nissan Versa recently, specifically at the windshield glass. It appears that possibly some of the polygons have the vertices read in a different order causing edges to be rotated. Easier to look at a pic.

So If I was modeling something symmetric I would make half and mirror. From the angle of the diagonals, it seems to me the modeler used a symmetry modifier on this object. BUT there are diagonals (marked in red) that are not symmetric to the other side. There are spots on other meshes where the diagonals seem rotated for no apparent reason. Perhaps this is what is causing the wonky faces?

Why is LOD0 important:
http://developer.nvidia.com/object/melody_home.html

Just a thought.

:/ I see lod1-5 has some edge rotation so maybe not.

Now that i look at it... the poly placement on the upper left corner look perfect to make a round corner but the "path" it takes is wierd.

I'll explain.



If you follow 1-2-3-4 you get the round normal corner. but the edges seem to follow 2-1-3-4, wich makes it do that wierd "wrong positioned" verts.

in response to " those red lines" perhaps those could be the Non planar 2 point polygons i mentioned several pages back, there are Thousands of polygons that are not actually part of the model present in every object, in most of the main body models (not meaning the cockpit) there are around 4000 polygons that do not belong there. They are also present in the cockpit, rotor and caliper models too.

See this post i made .. viewtopic.php?p=38301#p38301 They could be what those red lines are in your model.

Nobby

Honestly that doesn't make any sense to me. All my tool does is build a simple trinagle list and extract exactly as such, a list of triangles (3-point faces). The idea of there being a "2-point polygon" is really an oxymoron and quite rediculous to believe in, unless you really mean a 3-point polygon in which two points share the same coordinates. Also, 3-point polygons will always share the same plane by definition, so I'm not sure what removing non-planar polygons achieves, because there shouldn't ever be any, unless from the special case described above with shared verts. Regardless, I don't even think the obj format supports points or lines, just faces. Since I by no means consider myself to be an expert in this area, please correct me if I am wrong, but these concepts seem fairly trivial upon first inspection and I find it extremely hard to believe otherwise...

EDIT: I've just confirmed that there is something wrong with the export process, as there are lots of faces that have duplicate points, whoops...

EDIT2: Meh, I don't know what to think anymore. I can easily modify my app to not dump faces with duplicate vertices, but it seems that the problem originates elsewhere. In the image below, is a segment of the index data. As you can see, if treating it as a triangle strip (which my app does), it will produce duplicate verts per face.

f1 100, 101, 102
f2 101, 102, 101 <-- dup 101's
f3 102, 101, 103
f4 101, 103, 101 <-- dup 101's again
.....



Then I thought that maybe I should be treating the index data as a list of quads instead, but the image below proves otherwise since it shows an odd number of indices in some of the strips. There are also pieces with only 3 indices per strip so I really don't see how it can be considered anything else other than a triangle strip.



The only conclusions I can come to at the moment are that their .carbin tool is messed up and exports this duplicate information, or that they use a combination of quads and tris in each strip, possibly starting out with quads and ending with a tri if necessary. Using duplicate verts for a quad will emulate a tri, so it could very well be quad strips. Then in the case of only 3 or odd indices per strip, the gpu might see the delimiter and recognize that it can't render a quad, and will render a tri instead. I will test this theory later, but I somehow doubt it is what they are doing...

Any ideas? :X

Ernegien wrote: Regardless, I don't even think the obj format supports points or lines, just faces.

I'm not really sure the issue is this, because in the sentra's windshield one side is fine while the other messes up.

and by figuring they use a symmetry modifier they both should be equal, so I would bet it's a problem of reading order (I dunno if it makes any sense).

Like the image i posted, while getting the points of the corner to make the tris it seems to jump right to point 2 instead of going to 1 first.

this could be because when you create the meshes from the striped data you've caught the "wrong poly" sometimes, usually in small details where they're more clustered.