PDA

View Full Version : SDK Feature Request



garg
09-28-2005, 06:54 AM
- In order to speedup the drawing for plugins like VirtualTexture it would be good if we have a blit function from a buffer to another buffer (raster).

- To have access to more features from within a texture plugin. For example, to be able to re-implement those standard LW gradients within a texture plugin.

Lightwolf
09-28-2005, 08:11 AM
- To have access to more features from within a texture plugin. For example, to be able to re-implement those standard LW gradients within a texture plugin.
Surprisingly to evaluate a layered texture you have to pass a micropoly structure to LW, which never makes it to the procedurals though.

Yeah, a lot of stuff should be added in that area. UV support being an example. It would be nice if it was possible to pass a subset of the shader structure to procedural textures (for a number of reasons).

Cheers,
Mike

garg
09-28-2005, 11:30 AM
I know about this structure (beside I had realy some pain to figure out how to use it).

For example, what if my texture want to use another texture as parameter (thing needed by VisualTexture) well, in this "sub-texture" I don't have the standard gradients anymore. I must say that all this part would realy need a lot more work. At the end you need to code a shader if you want to be able to implement those things, when normaly you don't want a special shader, but just a standard texture (specialy since we have FPrime ;-) )

Lightwolf
09-28-2005, 12:33 PM
I know about this structure (beside I had realy some pain to figure out how to use it).
I guess that is the problem with a lot of structures. Did you ask on the plugin-ml or on SplineCage? (Yeah, I know, I prefer to hack around myself sometimes as well instead of asking ;) ).


For example, what if my texture want to use another texture as parameter (thing needed by VisualTexture) well, in this "sub-texture" I don't have the standard gradients anymore. I must say that all this part would realy need a lot more work. At the end you need to code a shader if you want to be able to implement those things, when normaly you don't want a special shader, but just a standard texture (specialy since we have FPrime ;-) )
I've got similar problems right now, I'm basically reverse enginering the complete image texture projection pipeline, and it is _not_ possible for a procedural to implement a clone of LW native image texturing, which is a real bummer. (I'm close, but no UV support...).
Spot sizes are also a different matter ... and I agree, FPrime support is crucial for any plugin related to surfacing nowadays...

As a 'personal' question (if you don't mind me asking) how to do you feel about the nodal shading network in LW9.0 ?

Cheers and regards from north of you...

Mike

garg
09-28-2005, 12:42 PM
At that time I posted a few questions, but nobody answered... maybe it was too complex, or whatever.

For nodal, I don't know yet how it will be, so I can't juge. So far it just seems another way (certainly a more convenient way) of texturing. I don't know how well this will be integrated within LW (as I know by myself how painfull it can be), so I wonder what they realy did here. I don't think it will offer the same number of procedural textures as we do, so I think it's more about another approach of texturing. Finaly I realy hope it's not like the pseudo nodal way to create expression as they sold us in LW 8 (which is realy a shame), and it would realy give us something.

I fear that some times, NT just give us a tool which has the name of the function we was asking more than actualy solving our need... if we take the nodal expression generator they gave us, it's not realy a nodal expression tool, it's just more or less an expression generator, and instead of this, they could have worked with Worley and give us a real real-time previewer which support ALL LW functionalities.

I hope I'm not too negative :-)

Alain Bertrand

Lightwolf
09-28-2005, 01:44 PM
Salut Alain,

At that time I posted a few questions, but nobody answered... maybe it was too complex, or whatever.
Sorry if I didn't catch it back then ...


I don't know how well this will be integrated within LW (as I know by myself how painfull it can be), so I wonder what they realy did here. I don't think it will offer the same number of procedural textures as we do, so I think it's more about another approach of texturing. Finaly I realy hope it's not like the pseudo nodal way to create expression as they sold us in LW 8 (which is realy a shame), and it would realy give us something.
Yeah, I hope it will include a decent SDK, with more variables to play around with than what the procedurals offer right now.
As for the expressions... I 100% agree with you, absolutely useless... *ducks for cover*
I hope it will work across channels as well, i.e. one master nodal flow to control different surface channels, may be even different channels on different surfaces or even other texturing instances (i.e. motions, displacements).


I fear that some times, NT just give us a tool which has the name of the function we was asking more than actualy solving our need... if we take the nodal expression generator they gave us, it's not realy a nodal expression tool, it's just more or less an expression generator, and instead of this, they could have worked with Worley and give us a real real-time previewer which support ALL LW functionalities.
I know what you mean, I also sometimes wonder why they waste time like this ;) - Must be marketing. However, from what I've read on the net, and heard about nodal, it seems to lead in the right direction, I just hope that the LW9 core and SDK will be expanded in the process as well. (Something I would for example love to have seen when the new AA modes were added ... don't just add them, turn AA into a plugin class and _then_ add the new modes).


I hope I'm not too negative :-)

It's not negative, it's passionate ;) I wouldn't ramble as much either if I didn't care. But I do care, so here you go :D

Cheers,
Mike

Lightwolf
09-28-2005, 01:47 PM
As a positive suggestion: How about if we collect a bunch of requests for the SDK, may be even going as far as 'prototyping' them, so that the dev team can see what we're talking about?
I think that sometimes this is the better way, especially since they presumably have no way of knowing what we want (or even _why_ we want it).

Cheers,
Mike

garg
09-28-2005, 02:51 PM
BTW one thing which NEED to be fixed at any cost :compbeati :

load/save of Vparam in binary mode
load/save of LWTextures in binaray mode

So far the only way to do it (as far as I found it) it's to store them as a text in a temporary file, read this file, and store it in the binary file:

void saveLWTex(LWTextureID tid,LWSaveState *sState)
{
LWSaveState *temp;
FILE *bin;
unsigned char *buf;
long size;

if(sState->ioMode == LWIO_ASCII)
{
txfunc->save(tid,sState);
return;
}

temp=fiof->openSave("temp.dat",LWIO_ASCII);
txfunc->save(tid,temp);
fiof->closeSave(temp);

bin=fopen("temp.dat","rb");
fseek(bin,0,SEEK_END);
size=ftell(bin);
fseek(bin,0,SEEK_SET);
buf=(unsigned char *)malloc(sizeof(unsigned char)*size);
fread(buf,size,1,bin);
fclose(bin);
unlink("temp.dat");

sState->writeI4(sState->writeData,&size,1);
sState->writeI1(sState->writeData,buf,size);
free(buf);
}

I realy don't think it's a good way to work, but I got some huge problems with those things, and that was the only way which was working for me. If some people out there was able to do it directly please let me know... even if I will not change the code in my actual plugins maybe it will be done for another one (next plugins :-) )

Lightwolf
09-29-2005, 02:57 AM
BTW one thing which NEED to be fixed at any cost :compbeati :

load/save of Vparam in binary mode
load/save of LWTextures in binaray mode

I haven't tried LWTextures in binary yet, but VParams work quite well, at least on shaders and procedural textures, which both save as binary.
I do make sure that I wrap them into their own section/block though.

Cheers,
Mike

garg
09-29-2005, 06:08 AM
Maybe I just missed to create the needed section then... My fault in this case.

Lightwolf
09-29-2005, 06:14 AM
Maybe I just missed to create the needed section then... My fault in this case.
If it ain't documented its not your fault ;)

Cheers,
Mike

RedBull
10-18-2005, 06:22 PM
My favourite subject!

I totally agree guys, I think Jarno who is now with NT for SDK advisement...
Is a hugely positive step forward for NT... (and us)

Not since Ernie, have we had someone with some pull at NT,
who does know many of the issues... we struggling programers of Lightwave
are facing, so fingers crossed the Fprime debacle, cost NT enough money,
that they take the SDK and LW core, to a better place.

I think your idea is great mike about prototyping classes, etc....
at least it's forward movement.....

LW Texture functions do need a clean up, and more access...
all of the gradient parameters should be accessible by now....

LW's biggest downfall, is not having MR, like every 2 year old Maya hippie will argue, it's the archaic arcitecture and design of a program, that simply grew up too quickly, and more powerful, than it was ever expected too...

I think when you look at programs like XSI etc.... (keeping an eye out for the Modo SDK) when a fuction, or tools is added to a new version, that function and tool becomes a part of the program...... Not just for users, but developers as well....

Now that PLD passes were added, surface thickness, new HV gradients....etc..
LW's SDK should of been updated, to offer these to us as well....
Or it's inclusion in the first place, is really a band-aid approach, to an internal bleeding process.....

I understand that LW's core, is going to take a real rethink if it's to be as open and accessible like Maya's etc..... And likely will never be, but i just think companies that ignore their 3rd parties, are ignoring revenue.....

If NT would spend more time making improvements under the hood,
all of us would be releasing more powerful intuitive, free and commercial plugins, which drive the end users experience anyway....

Anyway it's just my frustrated views... :)
LW has so much power under the hood, but it loses so much power through
drivetrain, to the rear axles, that it can hardly do burnouts....

Well an exaggaration, but you get the idea....
It's there you just can't access it! :)

Jarno
10-18-2005, 09:00 PM
Not since Ernie, have we had someone with some pull at NT,
who does know many of the issues... we struggling programers of Lightwave


There is actually a bunch of plugin hackers on the LW dev team now.

As you said, the real work is in the core. Many of the problems in the SDK actually reflect problems in the core.

---JvdL---

RedBull
10-19-2005, 01:34 AM
There is actually a bunch of plugin hackers on the LW dev team now.

As you said, the real work is in the core. Many of the problems in the SDK actually reflect problems in the core.

---JvdL---

Yeah, and i think NT have made it public, that they really do intend to
improve this area in the future, and having new blood, and insight with
Jay, David Ikeda, Yourself, and Bob at the helm, it's really starting to sound like they have the team, to move forward now.... Thanks Jarno.
Fingers crossed for LW9 and beyond.