Delgine 3D Tools & Content DeleD Community Edition
Forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

biomechanoids :)

 
Post new topic   Reply to topic    DeleD Community Edition Forum Index -> DeleD Plugins
View previous topic :: View next topic  
Author Message
jwatte
DeleD PRO user


Joined: 26 Apr 2006
Posts: 513

PostPosted: Sun Jun 17, 2007 7:00 pm    Post subject: biomechanoids :) Reply with quote

DNA Analysis by Mapping and Restriction and DS have been observed but do not lent fragments of different pepsin-treated
The mechanisms of aquaporin control in the side chains are different in the- and - ulate proliferation of gut epithelial cells
I have TRIED to use Kai for five years now and, once again I have been totally fucked by your sales pitch I purchased your Mini adapter and YET STILL my shit doesn't work!!! I am so fucking sick of s
 Bones & Joints  Elimination  Ener gy body. One form is ?good? cholesterol, called able variety of foods is probably enough in itself to ensure that you get the


Last edited by jwatte on Tue Sep 07, 2010 9:31 am; edited 2 times in total
Back to top
View user's profile Send private message
jwatte
DeleD PRO user


Joined: 26 Apr 2006
Posts: 513

PostPosted: Sun Jun 17, 2007 11:38 pm    Post subject: Reply with quote

Actually, another thing that would be useful would be a description of the DeleD rendering mode.

I thought that the different layers are all composed on top of a basic incoming color, and the end result (after multi-texturing) is then dumped into the frame buffer.

However, it appears as if the actual rendering is done using multi-passing, where each layers blend mode is expressed as blending between the texture and the frame buffer. This is... different. And not entirely useful.

I know you've been talking about re-doing the material system, so maybe this doesn't warrant more work, but what you really want to do is define a multi-texture stage, where each texture modifies the texture before it, and the light map comes last as modulative data, THEN there's a separate per-material blend mode for how the data gets dumped into the framebuffer.

I'm just sayin' :-)
Back to top
View user's profile Send private message
Paul-Jan
Site Admin


Joined: 08 Aug 2004
Posts: 3066
Location: Lage Zwaluwe

PostPosted: Mon Jun 18, 2007 6:53 pm    Post subject: Reply with quote

Good point about documenting the different enumerants, will put it into action.

About the multi-material-layer behaviour, this might be a nice time for a little background information: back in the days when we designed the material system, we wanted it to be intuitive to an artist: every material layer functions as if they are painted one by one (layered) onto the frame buffer. It's nice how the graphics API's have dictated the whole multitexturing v.s. framebuffer blend thing, but we wanted the layers to simply act like multiple layers of paint.

In effect, our approach has two major deviations from the way the underlying API's work:

a) The blend mode of the first frame defines the interaction with the frame buffer, not the multitexture blend.
b) When the blend mode of the first layer is set to replace, it really just means a visual replace of the content (i.e. it does a 'modulate' under water, not an actual replace which would also replace lighting etc.).

Since then we've learned most artists fall into either one of two categories:
1. People that don't bother with multitexturing anyway Wink
2. People that have seen enough other 3D drawing applications and/or rendering engines to have come to terms with the way multitexturing works (and come to expect things to work that way).


So in conclusion, the advantages of doing things our way are not that big, and like you say it does have some practical implications (like giving developers of import/export plugins a bit of a headache when dealing with it). However, the differences are not that major, so we are postponing the rewrite till a real compelling reason comes around...

p.s. Of course, the actual implementation of the system is done using multitexturing, with a fallback to multipass when not enough texture units are available. Not that there are many cards around anymore with < 4 texture units, but still... Very Happy
Back to top
View user's profile Send private message Visit poster's website
jwatte
DeleD PRO user


Joined: 26 Apr 2006
Posts: 513

PostPosted: Tue Jun 19, 2007 6:32 pm    Post subject: Reply with quote

How can you do it with multi-texturing if the framebuffer is included in each pass? There is no equivalent transform, unless you read the original framebuffer as a texture. The only case that you can do in a single pass is when you start out with Replace.

Anyway, I've found that it's usually better to model things on what the hardware can actually do efficiently. That way, you don't get into cases where you have to put in a bunch of limitations on what features you can use, and/or cases where there's something you know the hardware can do, but the system won't let you.

Here's the compelling reason, btw: Shaders :-)
Back to top
View user's profile Send private message
Paul-Jan
Site Admin


Joined: 08 Aug 2004
Posts: 3066
Location: Lage Zwaluwe

PostPosted: Tue Jun 19, 2007 7:07 pm    Post subject: Reply with quote

It's just multitexturing combined with a simple blendfunc.

And about the shaders: yeah, that's gonna be a rather big chance. Very Happy
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    DeleD Community Edition Forum Index -> DeleD Plugins All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum