ZEQ2 : Interactive Anime Experience

Tuesday, April 03, 2007

Did you miss Korin's place?
http://zeq2.com/site/viewtopic.php?t=434

Wednesday, April 04, 2007

When will we see Goku's textureless face? Or full Vegeta?

Wednesday, April 04, 2007

There will be updates every once in a while.

Wednesday, April 04, 2007

correct me if im wrong........but wouldnt that amount of polys/triangles lag

Wednesday, April 04, 2007

we do use more poly/tri's then average games, yes.
but most people don't know that textures use more resources then polygons do.

for examples:
1 512x512 texture requires the same as 500 polygons (just an example)
so.. if you would use those 500 polygons to recreate the detail that normally a texture would give you, you would get the exact same performance, this is exactly what we do with ZEQ2.
But ofcourse polygons don't get blurry when viewed up close, unlike textures.

Our models won't cause LAG, don't worry about it

Wednesday, April 04, 2007

Blaize wrote : we do use more poly/tri's then average games, yes.
but most people don't know that textures use more resources then polygons do.

for examples:
1 512x512 texture requires the same as 500 polygons (just an example)
so.. if you would use those 500 polygons to recreate the detail that normally a texture would give you, you would get the exact same performance, this is exactly what we do with ZEQ2.
But ofcourse polygons don't get blurry when viewed up close, unlike textures.

Our models won't cause LAG, don't worry about it

Nice to hear that. I didn't knew that textures could take so much resources and even more resources than polygons. And as you said polygons arent getting blurry. Thats good for better quality.

We are all waiting for new pictures

Wednesday, April 04, 2007

Damn! I would like to see a movie about it! That would preicisely show the perfomance!

Wednesday, April 04, 2007

We'd all like to see a movie about it Ravven =P

Wednesday, April 04, 2007

lets hope we will with the update....

Saturday, April 07, 2007

The concept is that more triangle equate to less memory usage, faster load times, more detailed depth (for lighting/shadows/outlines), and no loss of quality in comparison to a texture approach.

The downside to such a technique being practical is that you are going to introduce more strain on your GPU rendering times. You would honestly be surprised at how many triangles most cards can push, however. A Geforce FX 5700LE can push a quarter million triangles at playable speeds -- the trick is, it won't have to.

Being textureless is more than just an overhaul of detail, quality, and resource savings. It offers future advantages and much more system flexability via progressive meshes, a futureproof graphic/physics scheme that will never outdate, and a much more natural aesthically pleasing image at any resolution or range.

Saturday, April 07, 2007

Zeth wrote : The concept is that more triangle equate to less memory usage, faster load times, more detailed depth (for lighting/shadows/outlines), and no loss of quality in comparison to a texture approach.

The downside to such a technique being practical is that you are going to introduce more strain on your GPU rendering times. You would honestly be surprised at how many triangles most cards can push, however. A Geforce FX 5700LE can push a quarter million triangles at playable speeds -- the trick is, it won't have to.

Being textureless is more than just an overhaul of detail, quality, and resource savings. It offers future advantages and much more system flexability via progressive meshes, a futureproof graphic/physics scheme that will never outdate, and a much more natural aesthically pleasing image at any resolution or range.

Ok... This sounds very progressive 'n stuff. But isn't it more complicated way to do things? I mean isn't this textureless way of drawing more complicated than "old-skool" textures...

Saturday, April 07, 2007

Ok... This sounds very progressive 'n stuff. But isn't it more complicated way to do things? I mean isn't this textureless way of drawing more complicated than "old-skool" textures...

Depends on what you mean by "complicated".

More difficult to design? Yes.
More accurate? Yes.
Better looking? Yes.
Better overall results? Heck yeah.

Saturday, April 07, 2007

Let's hope this overall goodness won't become a resource-hog...

Saturday, April 07, 2007

holy trash that looks wicked

Saturday, April 07, 2007

Let's hope this overall goodness won't become a resource-hog...

*looks up a few posts*

Being textureless is more than just an overhaul of detail, quality, and RESOURCE SAVINGS. It offers future advantages...

Tuesday, April 10, 2007

just make a movie about it guys when you do there will be no more misunderstanding =)

Tuesday, April 10, 2007

just make a movie about it guys Rolling Eyes when you do there will be no more misunderstanding =)

How do you recommend we make a movie showing resource impact? How would this be any different from telling you raw figures and explaining the process in screen captures?

The real key to some of the techniques discussed is strong reading comprehension, personal perception to detail, and a good measure of patience for future information.

Wednesday, April 11, 2007

I'm wondering how you guys will hande details like those lines under DBZ characer their eyes,and the lines on their hair.
Also,is SV now unnemployed,I see his positition is "2D Character Artist".I guess he makes the HUD and sprites now ?

Wednesday, April 11, 2007

movento wrote : I'm wondering how you guys will hande details like those lines under DBZ characer their eyes,and the lines on their hair.
Also,is SV now unnemployed,I see his positition is "2D Character Artist".I guess he makes the HUD and sprites now ?

Well there will be no hud, but there are plenty of things he still could do.

Think of menu etc.. Besides that he can also model.

Thursday, April 12, 2007

His job is to now answer all of our questions on the question board.

Just kidding. (not that I have any say in that anyway )

But anyway....

You guys are lovin' geniuses.

That is all.

Edit: Oh wait, no one liners allowed.

Well, everyone who doubts the ingeniusness of this system, remember how much memory it takes to store a 512x512 picture. I'm not quite sure how these guys are storing it, though, so I'm not sure of that myself.

But they said it's about 500 polygons. I wonder if 500 more polygons is enough to regain the detail required.

Also, remember that pictures take time to draw too. I'd imagine textures would take more time to draw in 3d then texturelessfu, actually. Not that significantly much, but it's enough to give more space to easily regain detail while not having textures.

All in all, I'm curious as to what the specs are of textured Goku versus textureless Goku (like, memory usage, maximum fps possible, etc.) But it doesn't matter much.

Thursday, April 12, 2007

Actually I'm still skinning. We'll provide a few options that will suit everyone, for example:
We will have the high detailed models (textureless ones) and the lower polied models (textured) for low spec computers.

Other than that I'm working on lots of other stuff like characters facial expressions, 2D art like the inspiration poster, icons (About section) and lots of other random stuff =P
Basically, I'm far from being unemployed

Friday, April 13, 2007

I'm skeptical about this, especially with the dynamic LOD. Having the textureless option to save resources is an nice theory, but how well will it actually work and how much of a perforance gain will there actually be?

With the amount of ram modern computers have, the amount of ram modern graphics cards have onboard and the amount and resolution of the textures required for ZEQ2 is hardly going to touch the performance, especially if the lower end option is to use textures and lower poly models. As far as I know you're not going to have huge multi stage shaders using over half a dozen 1024 res maps for each object, are you? It would be basic cel-art style textures, not needing that high a res.

The worry is that while you're using the extra polygons for detail instead of textures, what's to stop that detail disappearing due to LOD collapsing the vertices when the detail would still be visible in a texture, such as the symbol on Goku's gi or the ornate designs in korin's tower?

I dunno, it's a good concept and textures certainly aren't needed as much in ZEQ2 as in a lot of other games, but I don't think there's any real benefit from negating them in favour of. Less textures, only using them where they're needed (e.g. a small texture for the Gi logo), would probably be better, save the polygons from things like that for actual detail like cloth or level design. Or maybe enhance the LOD by having the polygons sharply drop off at a certain distance and simple textures used?

Basically, from my understanding one way is not better than the other. Lots of large textures use a lot of memory and lack 'physical' details polygons give while just polygons take longer to render and lack the 'artistic' details textures give. I'd say that the greatest performance would come from a ballance of the techniques and use each to their uses to achieve the overall best results.

How far along is the implementation of the texture-less rendering and LOD system? Like, is it fully tested with movement through large, object-full scenes and taken some performance stats comparing texture use to textureless or is it still on the coding block with just basic tests being run to see if it works? It'll be interesting to see how well you pull it off if you do it as you say.

Also, to go a bit cross-subject, how does the LOD system work in terms of the environment? Is it purely object-distance based or will it decimate a mesh at varying levels based on element-distance? (e.g. a large, single ground mesh is at full LOD where you stand but a far away piece of the same mesh would be at the lowest LOD.)

Eh, this post has ranted on for far too long, but it's brought to you by curiosity and general musings on game design.

Saturday, April 14, 2007

Having the textureless option to save resources is an nice theory, but how well will it actually work and how much of a perforance gain will there actually be?

The reasons for going textureless weren't really to save resources, but rather to offer great accuracy and to futureproof ZEQ2 so that it would never be outdated aesthetically.

Texture-less offers higher levels of light, shadow, and collision calculations over textured methods. Since we have an actual 3-dimensional object in all regards, here are but a few advantages :

[Immediate Advantages]

• Lighting will wrap much more naturally
• Shading methods can be changed on the fly to a new style without requiring resource changes
• Mesh angle depth can be used as a factor for determining realtime silhouette and crease outlines
• Uses much less memory overhead than textures

[Future Proof Design]

• Shadows would be able to be calculated with full volumetric precision using the mesh data
• Raytracers will adapt and reflect more accurately
• Collision/Physics could be performed on a MUCH more precise area if using a triangle by triangle method

This is not to suggest that the method of being textureless doesn't have shortcomings. The increase in mesh detail means that the CPU/GPU will be more required than before. It alleviate this issue, we offer the aggressive LOD which insures that only the highest detail of the model is used based on range. Additionally, we do have a few other tricks up our sleeves, but we'll save those for another time.

It would be basic cel-art style textures, not needing that high a res.

This disadvantage with textures using outlines is actually more than you might think. We'd need a RIDICULOUSLY huge resolution to prevent pixelation/blur when up close to the model. Also, the mesh wouldn't be able to reflect and wrap shading as accurately and we'd lose that dynamic realtime feel for outlines that we've now captured from the series.

The worry is that while you're using the extra polygons for detail instead of textures, what's to stop that detail disappearing due to LOD collapsing the vertices when the detail would still be visible in a texture, such as the symbol on Goku's gi or the ornate designs in korin's tower?

We can control the LOD manually therefore choosing WHAT collapses and HOW it does so. General details (like a logo) at a distance would be preserved. If you pay close attention to the DBZ series though, things like minor details aren't visible at a range (rather it has a nice distance posterization/blur). The fullest level of details are only available at closer ranges.

Lots of large textures use a lot of memory and lack 'physical' details polygons give while just polygons take longer to render and lack the 'artistic' details textures give.

You'd be surprised what even a semi-modern GPU can push poly-wise. Couple the lack of "artistic" design with vertex/pixel shaders and you've got a win-win situation on your hands that ensures your product can survive future revisions unlike models before it.

While the techniques we employ wouldn't be fully applicable for a realistic game, they fit like a glove on a NPR styled one.

How far along is the implementation of the texture-less rendering and LOD system?

Fully implemented.

Like, is it fully tested with movement through large, object-full scenes and taken some performance stats comparing texture use to textureless

Performance has been tested on many scenes, one of which I cannot disclose fully. The load times are nil, the framerates are solid even on a mid-range card, and the visual results are golden.

Also, to go a bit cross-subject, how does the LOD system work in terms of the environment? Is it purely object-distance based or will it decimate a mesh at varying levels based on element-distance? (e.g. a large, single ground mesh is at full LOD where you stand but a far away piece of the same mesh would be at the lowest LOD.)

I think you mistaking Discrete LOD with Continuous LOD.

ZEQ2 uses uses Discrete LOD.

Discrete LOD is a process by which multiple versions of a mesh are pre-compiled and stored in a single file. These versions can be swapped out with the original at any given moment, but usually will do so based on distance or other occlusive factors.

Continuous LOD is a process by which polygons are procedurally deformed in REAL-time to generate a new form of the model. They are not pre-calculated, thus they suffer from heavy CPU usage. Additionally, CLOD techniques generally collapse models improperly or spastically even if you specify collapse zones. Costly and accurately ineffective, they have no place in ZEQ2.

Saturday, April 14, 2007

Ahh, so it's static LOD rather than dynamic? That's the bit that I got confused about, I thought you were using like a collapse map algorithm or something to that extent to do it dynamically for smooth transitions and not needing to create many different res'd meshes. Obviously, if the LOD's are done by hand then they'll be to be designed to look right. Dynamic mesh decimation for LOD can cause some spastic things to happen, especially when completely procedural, but if some sort of pre-computed data is used for discerning what to collapse in what order, it's not too expensive and can achieve a nice effect. But yeah, manually creating the LOD's will certainly give more accurate results for cheaper performance. Out of interest, how many levels of LOD do you have in it?

I also take it that all the big level meshes (e.g. the floor) are segmented to work well with the LOD system? It'd be very interesting to see a techdemo running and showing it in action, while I'm skeptical I'm very curious about it 'cos if it's pulled off as good as you say then it'll certainly be something to see, after all it is such a concept which is quite off the norm so not something to fully understand how it'll be from just chit chat

On a site note, what format are you using for the models? Your own or an existing one? Also are how are the levels handled, format wise? e.g. is there a 'world' format for all the vis data, entities, etc. and a 'model' format for the meshes, collision data, texcoords, LOD etc.? To follow further, if it's a propriatory format, is it binary/ascii/happy time photos/XML/something else based and how much pre-processing do they need? Like is it just an export directly to the format from a 3D App or is there a few intermediate formats which get compiled together?