This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=37

El Duderino, posted Fri Aug 08, 2014 2:30 pm (47)

---

I was wondering if anyone would be interested in helping me with EDGE.
More to the point, I can't get skin to work correctly.
I read the comment in edgegeom_decompress.h about reading the vertex data according the the quadword offsets (line 967 I think)
,but to no avail. And, in the one Playstation All Stars file I have, all the position data is exactly one quadword meaning it should be read sequentially anyway.
Even that is all *****ed up.
Anyway, here's 2 examples (tri-Ace).
Bunny is non-EDGE - skinning works fine. Doge is EDGE - skinning is all screwed up. (same over-arching format)
https://app.box.com/s/m3hfz2rnhk8ns3h3k23k

aluigi, posted Fri Aug 08, 2014 5:55 pm (51)

---

Just trying to understand something because 3d graphic is not my field.

Basically Edge acts as wrapper for zlib and lzma compression, so shouldn't we see compressed blocks in dodge.asf?

El Duderino, posted Fri Aug 08, 2014 11:45 pm (56)

---

Oh no my friend - this is something much more insidious.
It's part of the PS3 SDK focused on the Cell Broadband Engine and utilizing it to it's full potential.
The data in the files is plain as day, but there's something else going on somewhere.
It doesn't help any that in the SDK they're throwing around shuffle and rotate masks like they're going out of style.
I'm still a beginner when it comes to programming so trudging through that stuff is a real chore.
(I still have my learners permit and have to wear a helmet)
I can PM you more info if you want. I have a Winhex pos file with everything mapped out if that's worth anything.

semory, posted Sat Aug 09, 2014 6:44 am (59)

---

yeah, there is c source code in the sdk but it is a big headache. uncharted 2 also uses edge compressed vertex buffers. i tried converting that source once but some stuff just didn't make any sense. edge sdk also has custom compression schemes for index buffers and animation data, as well as standard lzma, zlib, lzss, and i think lzo.

there is also a pdf file doc that walk you through exactly how index buffer compression works, but the section on vertex buffer compression the dude is looking at, it is like, "wtf you talking about willis?"

aluigi, posted Sat Aug 09, 2014 10:42 am (62)

---

Now I remember why I'm not in the 3d formats reversing... too complex

El Duderino, posted Sat Aug 09, 2014 2:16 pm (65)

---

@ aluigi
It wouldn't be any fun otherwise.

@semory
Reading the delta compressed index data isn't a problem.
There's about 100 lines of commenting in edgegeom_decompress.h explaining it.
(nevermind that chrrox showed me how to read it to begin with )
The vertex "compression" isn't really compression from what I see.
Well, as far as position data is concerned anyway. The 24-bit unit vectors you could call compressed.
And maybe the X11Y11Z10N format. I guess it depends on how you look at it.
Reading those formats isn't an issue either way.

That's the trouble - near as I can tell, I'm reading all the data correctly (apart from the unit vecs), but the skin gives screwy results.

Also, maybe someone could help with the unit vectors?
This is mah code:

Code:

def rUnitVecs(data):
   spec = ['V0',10, 'V1',10, 'M',2, 'MS',1, 'W',1]
   reader = BitReader(spec, BitReader.BIG_ENDIAN)
   vBits = reader.read(data)
   
   vBits.MS
   V0 = vBits.V0 /2047.0
   V1 = vBits.V1 /2047.0
   mS = math.sqrt(1-(V0**2   V1**2))
   
   if vBits.MS == 1:
      mS *= -1
   if vBits.M == 0:
      vx = mS
      vy = V0
      vz = V1
      if vBits.W == 1:
         vy *= -1
         vz *= -1
   elif vBits.M == 1:
      vx = V0
      vy = mS
      vz = V1
      if vBits.W == 1:
         vx *= -1
         vz *= -1
   elif vBits.M == 2:
      vx = V0
      vy = V1
      vz = mS
      if vBits.W == 1:
         vx *= -1
         vy *= -1
   return (vx,vy,vz)

With 10-bit values the divisor should be 1023.0, but V0**2 V1**2 ends up being greater than 1 a lot which is very bad.
Not to mention a sure sign I'm going about it wrong.
And with the sign stored for the missing value, I figured it would be redundant for the W value to just flip it again hence the nested "if"s.

......did I mention fun???

EDIT: Whoops, I forgot. 20 bits for the values stored, 2 bits for the missing value, 1 bit for that value's sign, and 1 bit for W.