Messages

26

Team Avalanche / Re: *Team Avalanche: WMRP(WorldMap Retexture Project)*

« on: 2010-04-23 03:25:29 »

We wouldn't need to if the game had outstanding textures to begin with >.>

27

Troubleshooting / Re: 3ds max 2010 dissidia .obj texture errors!

« on: 2010-04-20 18:52:44 »

i didn't know 3ds had that feature! you are talking about 3ds right? and not mesh?

edit: i tried that and it just put the whole .png on the screen section or messed up(out of place) on his skin!
also i get "matlib" not found what the hell is that!?

You're not very familiar with 3D programs are you? ^^;

In Max, press 'M' it should bring up the material window, then find material 1, scroll through the list of options, one should say something to the tune of 'Apply Bitmap' click that and it should bring you to a file window. Open your texture. Now select the object you want to apply it to and click the checkered cube icon in the Material window.

All of this is from memory, so some menus may not be perfect, I've been using Maya for the past 4 years because I loathe Max's interface.

Cloud will have several textures, and you may have to reapply them until find the right objects' material.

28

Archive / AC Custom Models

« on: 2010-04-20 18:41:20 »

I gotcha, you like the cube-fisted look. THAT I can understand.

29

Releases / Millenia's custom models

« on: 2010-04-20 18:36:56 »

The only bad thing I can say about that image is that the FOV is terribly exaggerated. The texture is amazing.

30

Team Avalanche / Re: *Team Avalanche: WMRP(WorldMap Retexture Project)*

« on: 2010-04-20 18:34:53 »

The pinkness is accurate compared to my original PSX FFVII...

And quite frankly it can't be removed anyway as long as the sky is blue.

Whenever you add a translucent red object to a bright blue scene, it will look either pink or purple...

If you screen red over blue you get pink. Simple as that. Try it in photoshop sometime, you'll see what I mean.

Making it darker will only allow more blue to show through. Due to the blending method used, the lighter the color is the more opaque it is.

The advantage and reason they chose to use the Screen method, is that it allows images to have transparency without being encoded with any transparency.

31

Team Avalanche / Re: New Project

« on: 2010-04-19 03:52:24 »

What style are we wanting for field models?

Have we even decided to touch those at all before now?

Do we have a list of enemies that appear in the first few areas? I only remember a few myself... Are we going with the Retconned enemy style for the guard hounds and such or the old style?

What are our current limitations? I heard someone suggest that semitransparent textures are now viable... Is that true?

Input! I need input if I'm to consider this! =D

32

Archive / AC Custom Models

« on: 2010-04-17 20:15:04 »

Tifa from AC isn't nearly as hot as Tifa from original FF7 

You like the trailer trash look better? I always thought she looked like a hooker in the original.

In AC she was.... actually wearing clothes.

33

Team Avalanche / Re: [WIP] Team Avalanche's Graphical Overhaul

« on: 2010-04-17 20:02:42 »

The creases need to be darkened. Looks good though.

34

Team Avalanche / Re: Team Avalanche Main Cast Project

« on: 2010-04-17 19:59:58 »

Alright, well this is where I had gotten with Red a few weeks ago. Seems that while I was busy with life/other obligations, Max 8 took a crap dive, and I can't get assets into BodyPaint from Max 2010. -,-

So it's going to take me some time to get everything back to normal... assuming that it'll work that way.

Does his mouth open...? Because it does in the game... Just something to be aware of...

35

Team Avalanche / Re: New Field backgrounds/CG Cutscenes thread

« on: 2010-04-15 03:40:40 »

Thats an awesome start harro.

Couple of things that could help with the lighting/materials.

Some of the cartoony assets of that scene have a self lighted material.
Basically almost everything in that scene is self lighted if you look hard. Cept the floor it seems.
What software are you using? max? Look in the materials editor and turn self lighting to
50% or something like that. Its just a way to fake the glow in the dark look of the object.
That could help a lot to get that same look in the game.

Im pretty sure he uses maya. If this is the case all you need to do is goto material attributes and turn on shader glow.

EGADS! sl knows something about modeling now!? What did I miss!!?

36

Team Avalanche / Re: New Field backgrounds/CG Cutscenes thread

« on: 2010-04-14 23:14:54 »

Rendering can be any size, so basically whatever is needed is what is rendered.

Also, I'm not sure if you understand or not, but FFVII's maps were all high resolution models that were rendered in the first place. We are recreating those models within a reasonable tolerance of error, and rendering them at probably somewhere around 4x to 8x the original size so they don't look pixelated in-game.

As for a list of files... I don't think ANY scenes have been finished yet, and really there's no telling what can happen when many people work on one scene, you could get 3 steaming piles of crap and one absolutely amazing piece, or you could get all amazing pieces in which you are conflicted in your choices... or you could get all crap...

Many artists are better than one in my opinion.

If you want to help, pick your favorite place and have at it.


As for the supposed "sprites" for lighting... we'll do exactly what square did and cut away everything in the render except for the pixels we want to be in the foreground. Square made their layers after the fact, that's why the antialiasing is still present in scenes... Sometimes if you look for it, you can see the AA in front of the characters.

FFVII doesn't do variable or semi-transparency at all, so we simply have "opaque" or "transparent" pixels to worry about.

The only real issue is getting the scenes rendered at the same FOV and angle as the originals.

37

Scripting and Reverse Engineering / Re: Vincent Limit Breaks

« on: 2010-04-14 21:01:08 »

I'd imagine to do that you might need to program a window that contains those commands... I think they are probably only currently accessible via AI control, since it has direct access to the game's source coded skills... so technically IF his AI were modified he could probably use Heartless Angel or Ultima... Though I doubt he'd have animations for that and would likely cause issues...

That's what I'd assume... I know a lot less about FFVII's source mechanics than some others... I'm just basing this on what I know of other common practices in game programming.

38

Team Avalanche / Re: New Field backgrounds/CG Cutscenes thread

« on: 2010-04-14 19:30:41 »

Not bad. there are a few things that need work...

Railway car does seem off by a slight bit, perhaps too wide... the props are a bit small, as has been said, and the cut through the giant mog-faced tunnel wall...

They should spin much... much faster...

It is a very good start though, I will say that.

39

Team Avalanche / Re: *Team Avalanche: WMRP(WorldMap Retexture Project)*

« on: 2010-01-24 23:00:22 »

I'll take a look at the tracks if someone can get me the originals and the new base ground textures...

If you can't provide the originals I'll have to reinstall the game... which could take a while... I've lost my discs...(again... my damn cats decided to scatter all my CDs about my room... I can't find FFIX disc one either...)

40

Scripting and Reverse Engineering / Re: FF8 Models, How did Qhimm rip them?

« on: 2010-01-24 20:57:28 »

I see... I hadn't thought about using 3dvia on kvaks...

Thanks for the heads up, I'll definitely be using that info for great justice.

41

Scripting and Reverse Engineering / Re: FF8 Models, How did Qhimm rip them?

« on: 2010-01-23 06:13:48 »

arg, we still can't get models from FF8?

I wonder, the PC game is dx8 or dx6 based?

On the contrary, it is quite possible to get the battle models (eventhough they are somewhat twisted, it's easily fixed)  It is reportedly possible to also get the field models, but I have yet to do it or see it being done.

Beg pardons, but if you can get battle models, could you explain how? I've tried a few programs but most fail miserably to even run at all...

Also, this thread is currently concentrating on the field models, so far what you see here is the progress... I haven't looked around the web in depth lately, but it seems from the sites I visit, that we're the only ones actively pursuing this... or at least the only ones on a site I've ever seen...

It's entirely plausible that some tiny unknown site is off doing this very thing, but they are just that... small and unknown to me.

In the end, any information you may have is a possible benefit.


And I completely forgot MK64 was even here... I was honestly quite surprised to see him... (here anyway... there are a few other modding/3D exploration sites I see him at regularly XD )

...I really need to learn to recognize headers... one of these days I'll get something done...

42

Scripting and Reverse Engineering / Re: FF8 Models, How did Qhimm rip them?

« on: 2010-01-16 01:05:17 »

Edit: Didn't notice that the parts of the body (noticeably the hands) were flipped. I think I've fixed it in the script now.

Sorry, I misunderstood that the first time I read it... you may ignore my comment about reversed bones...

43

Troubleshooting / Re: really strange glitch with ultimate weapon

« on: 2010-01-15 18:58:41 »

When you used the clean  kernel, did you start from a previous save file?

If not, it's likely that whatever damage was done, is permanent.

It may be that some mod was glitched or improperly installed from the very beginning and you may need to start from a file made before the application of the mod, which if you're using multiple mods, may require you to restart the game, or never fight Ultima WEAPON or visit Cosmo Canyon ever again.


It may not be impossible to fix, you may be able to change a flag with a memory or save editor to have Ultima already be dead... But I give no guarantees.

44

Releases / Re: Simple Start Screen

« on: 2010-01-15 18:52:40 »

I'm assuming those textures are from the AVALANCHE visual reconstruction mod you have installed and don't come with your start screen.

Otherwise you should give them, us, and me, credit for making them... and also have permission.

If all of this is taken care of already, please don't read this post.



Erstwise, it certainly does look simple.

45

Scripting and Reverse Engineering / Re: FF8 Models, How did Qhimm rip them?

« on: 2010-01-15 18:38:59 »

 

I don't actually know how what I did works, but I'm now very close to proper bone rotations. Still need to fix the other issues though.

Some issues

• Gaps in UV
• Textures don't show up in render (Need to associate it correctly or something.)

Hmmm, I've come a long way since I started, when it had no skeleton at all and was just a clump of parts stuck together. (Those are stages which I didn't show here.)


Edit: Didn't notice that the parts of the body (noticeably the hands) were flipped. I think I've fixed it in the script now.

I've never liked Rinoa as much as I do in this post...

What is that black line coming out of her thigh? a bone?

Also I think you have the bones in the waist reversed; the rotation looks correct, but the bones themselves have the wrong legs weighted to them. I think after you fix that you can probably start finalizing little details... It certainly looks near completion in that image sequence.

46

Scripting and Reverse Engineering / Re: FF8 Models, How did Qhimm rip them?

« on: 2010-01-13 02:48:02 »

I have some documentation about quads and strips pertaining to PS2 rendering, they may not help much, but I'm posting them here just in case they might be of use...

Synopsis
A triangle strip is a speed- and space-efficient way of storing a set of triangles on a computer, usually for computer graphics.

Detail
Take, for example, a modern graphics processor, capable of drawing millions of polygons per second. One of the major limiting factors is not the triangle-drawing ability of the processor; without triangle strips often the limiting factor is the data bus between the graphics processor and the memory storing the triangles1. Triangle strips reduce the memory bandwidth needed by a graphics processor by not transmitting redundant information. Each triangle is comprised of three separate vertices, but in many cases you can find a set of topologically connected triangles which share common edges. Triangle strips exploit this fact. So what does this mean?

Consider a simple square, which would be stored as two triangles:

0--1
| /|
|/ |
2--3
Thus, the square is made up of the triangles (0, 1, 2) and (1, 2, 3)2. A naive storage format for this square would just store both those triangles, costing 6 (2 x 3) vertices. Notice how in both of those triangles, the edge (1, 2) is specified. A triangle strip simply stores that square as (0, 1, 2, 3), where the two constituent triangles share the middle edge (1, 2). In a triangle strip of length N, there are (N-2) triangles; with each triangle being a vertex and its two previous vertices. This means the square is now stored in 4 vertices, and if we wanted to add another connected triangle (sharing edge (2,3) with triangle (1, 2, 3)) we only need to add an extra vertex:

0--1
| /|
|/ |
2--3
| /
|/
4
This is extremely space efficient; in a perfect strip each extra triangle costs us only another vertex.

If you imagine a typical polygonal mesh, for example a triangulated teapot, you can see that the majority of the triangles share edges with other triangles around them. This makes finding long strips of connected triangles relatively easy, and indeed such shapes can be stored very efficiently using strips.

Given an arbitrary polygon soup, finding the perfect set of triangle strips which represent it is a difficult problem. There is a potentially infinite number of different strips you could choose to represent an object, but for efficiency's sake the strips used must be as long as possible. In fact, this process (known as triangle stripping or sometimes stripification) in an NP complete problem. However, armed with some simple heuristics you can usually come up with a near-perfect solution. There are a number of GPL libraries around for performing stripification, including a particularly good one called Stripe.

As you've seen, strips are space-efficient; it takes less vertices to specify a mesh using strips. However, it is also speed-efficient. In rasterizing a triangle, a graphics processor has to perform a fair degree of calculations, particularly if it supports something like programmable vertex shaders. When rendering a strip, if the previous two vertices are cached, then after the first triangle has been drawn, the next only requires one extra vertex calculation.

There's another trick that can be used; normally there's a set up cost associated with starting a strip on modern graphics hardware. So reducing the total number of triangle strips is beneficial too - this can be achieved using degenerate (zero area) triangles. Given two strips, you can stitch them together by duplicating the last vertex of the first strip, and the first vertex of the second strip, and then concatenating them. Consider two separated squares:

0--1 4--5
| /| | /|
|/ | |/ |
2--3 6--7
These squares can be expressed as a single triangle strip (0, 1, 2, 3, 3, 4, 4, 5, 6, 7) with four degenerate triangles (2, 3, 3), (3, 3, 4), (3, 4, 4), (4, 4, 5). As the triangles have zero area (which is quick to detect), they usually cost very little to process, and in most circumstances these long concatenated strips are more efficient than lots of small strips3.

Any task involving large numbers of triangles can benefit from triangle stripping, for example collision detection, or ray tracing.

1.Indexing vertices and storing vertex data separately to topology information is another common way of reducing the bandwidth, which is compatible with stripping.
2.Usually triangles are stored with a consistant winding order, I ignore winding issues here for clarity. Where winding order is important (e.g. on graphics processors) note that every other triangle's winding order is opposite, and this is taken into account by the hardware.
3.Some specialist applications (e.g. the PlayStation 2's rendering system) store an extra piece of information with each vertex: whether that vertex and its previous two vertices should be considered a valid triangle. This allows an even more efficient way of stitching triangles together; you can simply concatenate strips together and ensure the first two vertices are not marked as valid triangles. For example, using an asterisk to mark valid triangles, the two squares can be expressed as (0, 1, 2*, 3*, 4, 5, 6*, 7*) using such a system.

also, as I don't think any of that mentions normals, it should be noted that most systems use clockwise vertex orientation as one type of normal (usually facing the camera) and counterclockwise numbering denoting a the other(usually reversed, with the invisible side pointed at the camera)


So most quads, being drawn as two triangles, will be half invisible. Since one triangle is drawn as

Code: [Select]

1. .2 and the next triangle being  .1(2)
3.                           2(3). .3(4)
Thus making triangle 2,3,4 counterclockwise and having an inverse normal.


Does any of that help? (If you already knew that, I apologize, I'm not trying to belittle you. I just get so few opportunities to really do anything helpful)

47

General Discussion / Re: ff8 question (also a mod search)

« on: 2010-01-10 06:37:00 »

You could use Ifrit to modify each enemy's stats to be the same for every level...

That way there would possibly be a little variance, but they would still probably be a specific difficulty...

However, this would require you to edit all 140+ enemies one at a time... and no guarantees on how well it would work.


Honestly I can't see how the enemy levelling would be much of an issue... Unless you just suck at junctioning...

If you junction 100 Ultima's to roughly any stat at level 20, the enemies will still be in their 'low level' phase, but you'd be able to max out the junctioned stat...

I just don't think there's enough demand to remove that feature for there to be any attempt at it.

48

Scripting and Reverse Engineering / Re: FF8 Models, How did Qhimm rip them?

« on: 2010-01-09 23:55:38 »

So what you're saying, is that once I have a potential vertex pool, I start plotting two of the coords per vertex in paint... If it starts to look like a model shape, I probably have the right stuff. If not I may be looking at something else entirely...

Is that what you're describing?

(And on the subject of busy life stuff... that I can fully understand... it isn't easy being a fulltime student with a part time job and no method of self-transport...)


However, I should note that I'm not simply working on FF8... I'm on FF9, both .hack series' and a number of other games on and off at any given moment, as well as being a 3D modeler for my own games... If I devoted all my time to one format... I'd probably be able to crack it at some point(or have a severe mental break).

However, my previous statement was referring mainly to the fact that I still can't get my headers to read properly even when they are fully documented...

When I read a header that tells me a file should start or end at a certain point in the data... I look at that part and it's either well after the end of the file or it is in some random spot after the file has already started... so instead I look at a relative point to the beginning, or end of that header, or the main header, or the end of the previous file, etc... but for some reason, even though I know the documentation is good, the headers don't seem to point me to where they should... (meaning I'm somehow reading them wrong...)



In any case... none of this helps the FF8 formats so I guess I'll stop.

49

Scripting and Reverse Engineering / Re: FF8 Models, How did Qhimm rip them?

« on: 2010-01-07 23:19:35 »

Oh how I wish I had he skill at spotting the relevant patterns for data structures like you guys have... Even with well documented headers I can't seem to make my bytes fit right... nonetheless find a vertex pool...

but regardless, I'm glad to see I'm not the only one still interested in getting a good look at 8's graphics.

50

Scripting and Reverse Engineering / Re: FF8 Models, How did Qhimm rip them?

« on: 2009-12-31 02:45:34 »

It may or may not look like much to you, but it looks very promising in my opinion.

I can't say I remember too much about the state of the previous script... but this certainly looks like progress to my eyes.