Might want to look into this.

http://forums.cgsociety.org/showthread.php?f=59&t=996710
[1] http://www.youtube.com/watch?v=F9oLyOwbFp0
[2] http://www.youtube.com/watch?v=0fTRUVpPbGw

Hi vodkamartini - it looks interesting, but there does not seem to be any specific information available. Some details would be good to know like does it require particular high end GPUs, and how does it deal with shared edges on trimmed surfaces, are they meshed in a watertight way or are there potentially cracks between each surface where they come to a common trim edge?

There are several kinds of processes that say they do trimmed NURBS but don't really do a full fledged "watertight" mesh production... Not sure if this is like that or not.

- Michael

That reminds me of OpenCL for ATI cards. Sony Vegas implemented it and the performance difference was incredible on my ATI workstation card. Houdini was talking years back about it also as the preferred technology as it was used by ATI and NVIDIA... and Houdini 11 does incredibly temps to speed efficient rendering on my computer. Wonder if OpenCL 1.0 could be used for something like MoI.

Hi southpaw,

> Wonder if OpenCL 1.0 could be used for something like MoI.

There isn't really much in MoI that would be able to take advantage of that - GPU processing tends to work best in situations where you have a mass amount of data but the computations being applied to the data are relatively simple, and easily distributed into separate work items.

MoI does take advantage of multiple CPU cores when generating export meshes though, and I would like to make use of multiple CPU core some more in the future. For most of the stuff that MoI does, multiple CPU processing tends to be a better fit than GPU processing. The other part that is not so good about relying on GPU processing in particular is that it tends to require an advanced and more expensive graphics card.

- Michael

""""""""MoI does take advantage of multiple CPU cores when generating export meshes though, and I would like to make use of multiple CPU core some more in the future."""""

Is there a possibility to have an option to make it more "CPU only".. In other words, no out of memory situations? Like just crunch until done, no matter what the task..

Hi Burr,

> Is there a possibility to have an option to make it more
> "CPU only".. In other words, no out of memory situations?
> Like just crunch until done, no matter what the task..

Well that could be possible for certain tasks, if the thing being calculated fits in a fixed amount of data, like for example if doing a calculation where the result is just a single number or something like that.

But generating polygon mesh data is much different than that - instead of just generating a single number result, polygon mesh data may have hundreds of thousands of separate points making it up and a lot of polygon faces as well.

There isn't really any way to create a result with say 500,000 points in it without allocating memory to fit 500,000 points...

So it isn't possible to generate something that involves a large quantity of data without allocating memory to hold all that data.

Well... then again I suppose with certain kinds of data it could be possible to write data to disk as it's created and not store it all in memory at the same time. But polygon mesh data does not really fit with that very well because the data has sort of links between various pieces like with faces indexing several different points and having points shared between faces. That makes it not really fit with a kind of "write the file incrementally as you go" type of processing.

- Michael

Thanks for the explain...

The other thing is that even in the kind of case where it would be possible to write a result to disk incrementally as it was being calculated, that kind of processing would mean you would not get a chance to see it displayed on the screen so that you could tweak settings and whatnot.

- Michael

It's a good answer.. I was being curious as the recent meshing I was trying on the .0000006 fillet file (rediculous) but also most recently on a terrain mesh where I am going to need millions and millions of polys... I guess this is why these things need the higher end workstations and minny super computers.. I'm going to upgrade my RAm soon for a few other poly apps..

Was there any way to get MoI any more than the 4 gigs?

Hi Burr,

> Was there any way to get MoI any more than the 4 gigs?

No, not currently - 4 gigs (usually more like around 3.6 or so actually) is the most a 32-bit program can address.

But it does help a lot to run on a 64-bit OS though - on a 32-bit OS you'll actually only be able to get 2 gigs (more like 1.6 usually) actually allocated but if you're on a 64-bit OS there will be 2 more gigs available for MoI to use, provided you have that much RAM actually of course.

- Michael

Yeah, I only have 4 at the moment, but I did upgrade the OS to 64 bit, So will be adding more RAm for someother apps..

My current computer actually pushes to like 97/8 percent before MoI crashed... Something like 3.9 gigs or something... pretty good. :o

Maybe that was MoI with 3.6 and the other stuff using the other part.

Are you saying that OpenCL would useful for things like arrays, but not much else? In MoI I mean.

Hi southpaw,

> Are you saying that OpenCL would useful for things like
> arrays, but not much else? In MoI I mean.

Yeah, it's just more generally suited for processing big arrays of somewhat more primitive data. For the most part that doesn't really fit in with a whole lot of areas in MoI as compared to something like render engines for example.

- Michael

"Arrays" as in "groups of things".... Not the command "Array".

Hi Burr - yup, that's "array" in the programming sense of the word.

- Michael