Perspective Projections

[sibarrick]

I could do this in an otl but not the vex op..... maybe I'll update the one on exchange. See how popular it is first, no point changing something nobody wants anyway.

[Mario Marengo]

Hi Simon,

I just sat down to read this thread... interesting stuff!

You mention that this will eventually be done "outside of Houdini", so the thoughts that popped into my head as I read the thread may not apply, but here it goes just in case...

Why not embed all the information you need at render time?

You have access to all this info inside a surface/light shader, so maybe you can make use of it at that point (and stash it into different rasters), instead of re-engineering the world->object and object->NDC transforms after the fact.

Here are some things you can do, which may give you some ideas:

Light shaders can export the NDC position of a surface point:

light myLight (
      //...//
      export vector Pndc = 0;
   )
{
   //...//
   Pndc = toNDC(wo_space(Ps));   // export NDC position
}

The surface shader could then gather this info and calculate the rest itself, stashing the data into slots indexed in some way that's controllable by the user. Here I chose to map light names to export "slots", but you could use some other mechanism that's more appropriate/convenient:

surface mySurface (
      // Map light names to export indices
      string Light1 = ""; // name of light for export slot 1
      string Light2 = ""; // name of light for export slot 2
      string Light3 = ""; // name of light for export slot 3
      // Export data
      export vector Ps1=0,Ps2=0,Ps3=0;       // light-space pos
      export vector Pz1=0,Pz2=0,Pz3=0;       // light-space Z-depth
      export vector Pndc1=0,Pndc2=0,Pndc3=0; // light-space NDC
   )
{
   illuminance(/*...*/) {
      string lname = getlightname();         // get this light's name
      if(lname==Light1 || lname==Light2 || lname==Light3) 
      {
         matrix ML    = otransform(lname);   // world->light transform
         vector LPs   = P*ML;                // P in light space
         vector LPz   = LPs.z;               // Pz from the light
         vector LPndc;
         if(!limport("Pndc",LPndc)) LPndc = 0;
         if(lname==Light1) {
            Ps1 = LPs; Pz1 = LPz; Pndc1 = LPndc;
         } else if(lname==Light2) {
            Ps2 = LPs; Pz2 = LPz; Pndc2 = LPndc;
         } else {
            Ps3 = LPs; Pz3 = LPz; Pndc3 = LPndc;
         }
      }
   }
}

I haven't tested the above so there may be some typos and such, but you see what I'm getting at: perhaps you can save yourself some grief by embedding all you need in the deep rasters?

Cheers!

[edward]

I could do this in an otl but not the vex op..... maybe I'll update the one on exchange. See how popular it is first, no point changing something nobody wants anyway.

17495[/snapback]

It might be hard to judge popularity on the Exchange right now as it's still technically in beta and so I wonder how many people actually go through there on a regular basis.

[sibarrick]

Hi Mario,

Yup I thought about that but I'm talking of a standalone app that needs to comp possibly 100's of layers as quickly as possible. The idea is to give our anatomy users the ability to view whatever structures they like in the same image, at the moment they rely on our pre-rendered selections. Because of this I can't really afford to add too many extra planes of data when storing one or two small matrices will do the trick in a much more space efficient way. Memory will be an issue because this app has to run on a "normal" pc, so loading up color, Pz, alpha is already pushing it a bit.

Also, although at the moment for us it's an outside app, as I got into it I realised it might be more generally useful, in that case rendering a Pz plane is easy, but getting people to either add an ectra pass with a special shader or modifying their own shaders to create the necessary planes seemed a tad more complicated, this way is nice and simple for the user.

I even had another use for it myself the other day but I hadn't finished it at the time. I was having to render a new image out of two existing projects and in order to combine everything I had to bring it all into one file, since we are talking about 1500+ objects in each file this was no trivial matter, however if I could have just rendered each one independently and still been able to comp them with shadows it would have been easy.

Hi Ed,

Exchange might only be in beta but many ops on there have 300 or so downloads. Still it won't be a hard thing to change so if I get a mo i'll change it to add an M plane as an option.

[Mario Marengo]

Hi Mario,

Yup I thought about that but I'm talking of a standalone app that needs to comp possibly 100's of layers as quickly as possible. The idea is to give our anatomy users the ability to view whatever structures they like in the same image, at the moment they rely on our pre-rendered selections. Because of this I can't really afford to add too many extra planes of data when storing one or two small matrices will do the trick in a much more space efficient way. Memory will be an issue because this app has to run on a "normal" pc, so loading up color, Pz, alpha is already pushing it a bit.

17498[/snapback]

Ah, I see. Yeah, I figured there might be some practical reasons why you didn't choose to go that route, but I thought I'd mention it anyway just in case.

About a year or so ago (seems like an eternity, but I think it was around version 6.0), back when I started my (ill-fated) crusade for adding a *real* world space to VEX, I had also requested that they store space matrices in shadow buffers (.pic, .rat) and that this information be retrievable from VEX. PRMan has this feature, I've used many times, and it's very very handy. Needless to say, it would have saved you a lot of headaches in this particular application. Oh well... <sigh> ... I think those suggestions are still sitting on the same shelf as ray labels

Cheers!

[sibarrick]

I had also requested that they store space matrices in shadow buffers (.pic, .rat) and that this information be retrievable from VEX. PRMan has this feature, I've used many times, and it's very very handy. Needless to say, it would have saved you a lot of headaches in this particular application. Oh well... <sigh> ... I think those suggestions are still sitting on the same shelf as ray labels

Cheers!

17503[/snapback]

That would have been very handy. Still I learnt a lot doing it the hard way....

[edward]

Simon, so are you guys going to be doing this in hardware then?

[sibarrick]

No just heavily optimised software. It doesn't have to be real time just not so sluggish you can't use it and not so memory hungry that it kills your machine.

We've done tests with 30-40 odd objects and without shadows it comps a complete frame in less than 0.5 seconds, of course once you have the complete frame you only need to update the area of the image that changes, so we'll probably end up storing a completely comped frame and start with that. With clever presorting and the use of bounding tests we hope we can get some pretty decent speeds out of it. Probably we'll just have the shadows as an option to turn on once you are happy with the rest of the image. Then you would either save to disk or print it out.

The really trick bit is transparent objects, were trying out atoring our own type of deep rasters kinda like deep shadow maps but this hasn't been tested yet.

I'll let you know if we get any further with it, at the moment the programmer working on it is tied up with other jobs and this one keeps getting pushed to one side. But at least now all the theory is in place.