How To Make Lightwave Faster On The Mac. Calling On NewTek's New Mac Programmer. :-

[Ed M.]

OK, apparently there is a new Mac programmer on NewTek's Mac dev team. This fellow has been rumored to have contributed to the MacLW forums on occasion - regrettably, I missed those posts. Perhaps we'll get another chance at meeting this individual again in this thread.

I thought it wise and beneficial to open a dialogue with the new Mac programmer and perhaps other members of NewTek's Mac dev team in the hopes of understanding some of the things they do when optimizing for the Mac. The soul purpose of this thread will be dedicated to understanding how the dev team approaches the Mac with respect to code optimizations as well as providing valuable information and tips that can be implemented when optimizing for the G5. What's more, it will give Mac-users and NewTek programmers the chance to develop a rapport all in the hopes of learning something new. Hopefully someone at NewTek reads this.


Let's begin...

It's been asked by many people, what other (types) of optimizations can NewTek do that will make Lightwave absolutely scream on the G5 that they haven't already done for the G4 machines? I think people are assuming that the code has already been optimized as much as it can be and that there is no performance left to be had. I feel that this is incorrect. My initial thoughts when asked this question were:

- How about just better [Mac] coders -- people more familiar with the Mac and Mac programming? - How about a more platform-specific application?

Then I got a little more specific...

- How about starting by adding some parallelism in their software? ... if developers aren't using more parallelism then they are throwing away 80%-90% of the performance they might otherwise expect and this is even before bringing AltiVec into the equation!

I also went on to mention that the G5 is *not* the G3 or G4 and that there are code segments in a lot of current apps (perhaps even Lightwave) that will completely cripple the G5, so testing these apps on different platforms and using the results as some sort of benchmark is biased, and is therefore a bad indicator for performance comparisons -- the code will be sub-optimal.

Once again, if those apps which are being tested are optimized and compiled for the G3/G4 without replacing the appropriate segments and making tweaks for G5, then the code is nothing more than highly sub-optimal.

If developers read the G5 optimization pages at Apple or information gathered from other resources/lists/message boards discussing optimizing for G5 then it will be clear that the code for earlier PPC processors very often employs such things as: Data Cache Block Allocate (DCBA), Data Stream Touch (DST) and Data Cache Block Zero (DCBZ). These functions will severely cripple a G5's performance and show it as a poor performer when tested against other platforms running the same application. These need to be removed and replaced with the appropriate optimizations for the G5. The next thing I touched on was compilers.

Some compilers will offer more performance gains than others, but it's one thing that may raise a few eyebrows.

As explained to me by a developer/friend, one thing about optimizing compilers is that they can't optimize if the optimizations are already done (and done most effectively) for them.

These compilers can *try*, but they aren't going to get a net speedup over what you already have (if they were indeed done right the first time), since there is no performance left to be had.

This is why developers (and users) should wonder every time they assume something like:

"We have some really optimized code for such and such platform" (i.e. the Mac)

"Compiler X gave us a 60-80% speedup!"

This would certainly be an endorsement for compiler X, but it certainly isn't exactly saying much for your coding in the first place -- that is if your code was actually optimized or taking full advantage of the platform like it should have been from the start!

However, lets say for sake of argument that it *was* (correctly) optimized from the start, then we could also surmise that the speed difference happened because the other compiler(s) was/were actively sabotaging the code and causing it to slow down for whatever reason.

This is not good either way because in some remote cases with actual optimized code, an optimizing compiler:

tends to bloat the code through inappropriate inlining and loop unrolling of non-critical regions.

For instance, what this new IBM compiler might be showing is that there is a LOT of poorly coded shrinkwrap Mac apps floating around the market. That is *if* there is a performance gain associated with it.

So, the question comes down to this:

Were the other compilers crippling the code or was it that the code was not as optimised as had been thought and the compiler was assuming the role of the corrective element?

Either it's bad code or poor compiler performance that could account for a lot of wasted performance gain. Either way, it shows that the Mac could be at a disadvantage one way or the other.

I asked a developer friend familiar with 3d programming and PPC optimization. He had these tips to share:

With respect to programming a 3D app and optimizing it for G5...

Avoid float <-> int conversions as much as possible. The old rule that integer is faster than float doesn't really hold for the G5. It can pay off to have an integer loop counter as well as a floating point loop variable that is maintained in lockstep.

When choosing algorithms, think parallelism. You have a lot of floating point execution resources available (two scalar single/double
precision multiply-adds each cycle, plus four vectorized single precision multiply-adds each cycle); just the scalar FPU pipelines alone can be busy with up to 14 floating point adds _and_ multiplies at any point in time, so you really want to have a lot of independent work for them to handle in parallel. This can mean handling several primitive objects "at once" or rasterizing several pixels "at once", or tracing a bunch of rays "in parallel" etcetera. Try to make your data structures reflect this parallelism as well; i.e. things that are calculated in parallel should be
in adjacent memory locations if possible. It makes no sense to try and saturate the FP pipelines when memory latency is the real bottleneck.
Emphasizing 'locality of reference' makes sure you get to use most of the available bandwidth before you run into latency problems.

If you can verify that single precision floating point math meets the accuracy standards of your application, consider using AltiVec. When you
have parallelizable algorithms as outlined above, it is usually simple to make use of AltiVec. If you are really crazy about performance, learn
about the PPC970's inner workings and investigate the possibility of using vector FPU and scalar FPUs in parallel. This is very tricky, but can
theoretically bring the available FP throughput up to six fused multiply-adds per cycle.... <cont>

Download CHUD from Apple. Profile the executable with Shark. Read Apple's technote on optimizing for the G5. If there doesn't seem to be a single "hot spot", or if there seem to be no opportunities left for optimization, use the CHUD tools to see whether cache misses are a problem. In that case, try to improve the data structures. Are elements grouped according to usage? Locality of reference is important here, but also the distinction between (mostly) read-only values and values that keep being modified. Did the compiler insert a lot of pad bytes? Then rearrange member variables, starting from larger data types (doubles, long long int) over data types with potentially varying size (pointers, long int, int) to smaller data types (float, short, char). This should reduce padding to a minimum and helps making better use of caches. If padding is still a problem, consider "struct of arrays" versus "array of structs". If the memory accesses are fairly regular, experiment with prefetch hints.

Hopefully this is a good start.

--
Ed

[danilo]

It is.
(good start)
danilo

[Beamtracer]

Originally posted by Ed M.
OK, apparently there is a new Mac programmer on NewTek's Mac dev team...

...Perhaps we'll get another chance at meeting this individual again in this thread. Please be kind to Scott. There is no obligation for him to appear on this forum, so everyone should be nice to him, whether we agree or not with what's being said.

I think it's a positive move from Newtek to hire Scott to specifically look after Mac optimization. Remember he inherits the present code from previous programmers, and the budget for optimization would be decided by upper management.

Scott indicated in a previous post that Newtek is already having extensive talks with Apple about optimizing for the G5.


-----------------------------------------------


Ed, your post is an interesting read. It seems that parallelism is the main optimization being suggested.

[Ed M.]

I just hope this thread gets noticed by NewTek and picks up momentum. It's probably something I should have done sooner.

--
Ed

[Beamtracer]

Originally posted by Ed M.
I just hope this thread gets noticed by NewTek and picks up momentum. It's probably something I should have done sooner.

It must be only a month or so away until the release of Lightwave 8. I don't know what they could do at this late stage. I'd imagine they must be into the beta testing phase.

Newtek always releases a free upgrade between paid upgrades. For example, LW6.5 and 7.5 were free to those who had paid for the previous versions, and were just as significant upgrades as the paid ones.

Chuck hinted that Newtek will be looking at more Mac-specific optimization in a subsequent revision of Lightwave. I interpreted that as maybe LW8B, or LW8.5.

[Ed M.]

I'd just like some type of reply from the Lightwave dev team for the Mac. I believe that if taken seriously, this thread could prove advantageous to the MacLW community in that performance could be increased significantly. I'm hoping Ted (eblu) and Scot (tallscot) are lurking. I always look forward to their posts.

--
Ed

[js33]

Ed,

I wonder how these optimizations apply to 64 bit? Are the ops you quoted dealing with 32 bit specific or 64 bit? I wonder if by simply making LW 64 bit would take care of most of these optimizations or if it all still needs to be tweaked manually?

Cheers,
JS

[Ed M.]

Those optimizations will help G4 as well as G5, but G5 will benefit much, much more. They are neither 32bit nor 64bit specific, but the G5's architecture sure opens up a ton of resources for NewTek.

--
Ed

[Ade]

Just read maxon optimised cinebench for g5 and got a 25-30% higher score and reached above their expected goal.
DP2ghz
previously -403
new- 506

So NT can do some speed ups too.

[hobold]

The quoted optimizations are not specific to either 32 bit or 64 bit machines. (In fact, further increasing the bit width does not necessarily lead to further performance improvements, because there is a point when the machine is finally "wide enough". Eight or sixteen bits were not enough for what people at large wanted to do with computers, but 32 bits carry you pretty far. Today only a few applications really require 64 bits; for the rest of us, 64 bits will only become relevant when we routinely work with data sets over 4GB in size.)

Parallelism is indeed the key to high performance on the PPC970 (G5), but that is true for all of today's microcomputers. The thing that is new with the G5 is the unusually high degree of parallelism inherent in the G5's floating point hardware. Its floating point pipeline has seven stages, so you can start working on six other calculations before the first operation delivers its result.

Seven in-flight instructions looks fairly harmless, and is in the same ballpark as what Athlon and Pentium 4 handle. But for the G5, a floating point instruction consists of up to two arithmetic operations: a multiply and a dependant add (i.e. you only need a single instruction to calculate x = a*b + c). So in terms of actual floating point operations, a single one of the G5's floating point pipelines alone needs roughly double as much available work (as contemporary 'x86 processors) to run at full efficiency. And the G5 has two of these floating point monsters on chip, so we end up with up to 28 individual floating point calculations being worked on in any single clock cycle. If you use AltiVec, parallelism increases by another factor of two compared to the scalar execution units as described so far. And finally, saturating all available floating point hardware (both scalar and vector) would juggle with close to 100 individual arithmetical operations at any given moment and would complete twelve of those on each cycle ...

At the same time, the G5's integer execution units look quite underpowered, especially compared to the massive floating point resources. This is yet another characteristic where the G5 is quite different from the 'x86 machines.

All in all, the notion of what is fast and what is slow on the computer differs quite significantly between 'x86 and the G5. One cannot trust the compiler to handle these differences alone, because the choice of algorithms has a profound influence on available parallelism, and this choice has to be made by a human programmer.

The drastic performance increase of Cinebench due to optimizations for G5 is probably not representative. As far as details are known, it appears that the "old" Cinebench has hit an especially weak spot of the G5 (float <-> int conversations in a critical inner loop), while the "new" Cinebench avoids that and also benefits from a special strength of the G5 (hardware for square root calculation, which previous Macs had to do in software). But it is to be expected that new "G5 versions" in general can very often notably improve performance over existing executables, because the G5 also differs quite a bit from previous PowerPC processors (as used in Macs).

[Ade]

Originally posted by Ed M.
I just hope this thread gets noticed by NewTek and picks up momentum. It's probably something I should have done sooner.

--
Ed


Or Panini ?
whoevers first?!

The trouble is Apple has been taking too long optimising OPEN GL for macs, we severly are being in OGL to pc's OGL.
Its been 1 year sice ppl complained about the parity.
I seriously doubt asking for optmisatiosn will ahppen, its more like PIXAR or some big company who wouldcomplain about g5 being crap then apple would act.

I feel Newtek/Alias/Maxon should form a 3D team in Apple and talk what they feel should be the road ahead.

[Chuck]

Hi, Ed!

Well, it seems to me that the intent would certainly seem more "wise and beneficial" if you didn't start the thread by talking as though things that are absolute matters of fact might not be true. It's a fact that Scott reads and has posted in the forum, and it's a fact that other NewTek staff review the forums as well. There is no reason to talk as though these aren't true unless your intent is to make those less familiar with the goings on in these forums think they aren't true, which would understandably then tend to make them think ill of NewTek staff. I'm not sure why you would think this is a helpful approach, let alone part of being "wise and beneficial".

A dialogue about the direction of Mac development is a good idea and has in fact pretty much always been a part of this forum. You've contributed greatly to such discussions in the past. Moving that dialogue to a phase of discussing the potential of the new G5 systems and the opportunities they offer is certainly timely, and we're very pleased with the discussions we're having with the Apple folks in that regard, and most certainly are ready to engage with our Mac users for productive discussions about the potential and how best to take advantage of it as well.

To acquaint you with what you've missed and to dispel any doubts raised regarding Scott's posting being fact or rumor:

http://vbulletin.newtek.com/showthread.php?s=&postid=70369#post70369

http://vbulletin.newtek.com/showthread.php?s=&postid=71128#post71128

http://vbulletin.newtek.com/showthread.php?s=&postid=76794#post76794

http://vbulletin.newtek.com/showthread.php?s=&postid=76867#post76867

http://vbulletin.newtek.com/showthread.php?s=&postid=76876#post76876

http://vbulletin.newtek.com/showthread.php?s=&postid=79103#post79103

[eblu]

ade, usually you spell much better than that (I'll chalk it up to tiredness), I have to assume you think that Apple's openGL is less optimized for macs than it is for PC?

my experience is the opposite actually. true Apple has serious holes in its openGL implementation, read: high end graphics cards, but for the most part Apple has been aggressive and very intelligent with regards to the openGL implementation in Mac OS X.

heres a short list of interesting developments.:
Apple stays current with the SGI release of OpenGL, Apple updates released in most cases a month or 2 behind SGIs updates (usually ahead of windows).
Apple is now heavily involved with the future of Opengl, freely giving away Cross platform code for integrating quicktime and freely giving its resources and information from the late Quickdraw 3d, to help mature OpenGL into a HIGH level 3d framework.
Altivec acceleration of OpenGL.
seriously low level access to system resources for OpenGL from the start, something that Windows lacked because it was designed without thought for OpenGL(its a legacy issue).
and when Apple realized they couldn't get Quartz video acceleration for about 10 years, they turned that Achilles Heel into a boon for OpenGL. They developed Quartz Extreme, which was a blending of Quartz and Opengl, throwing many internal resources into making OpenGL fast on macs, and securing a future for that kind of development. This created a small core group of OpenGL experts at Apple, people who are learning every day, and freely giving what they learn away.

OpenGL is on the fast track at Apple these days, not just a buzz word, a centerpiece of the OS like quicktime, and its developing much faster than on any other platform. I suspect that there is a lot that can be done at Apple to speed openGL, and from what I have seen, Apple appears to be actively working on that. Apple seems to get the whole "working with other companies" thing these days, so I have difficulty believing that apple is Not doing anything to get a high end card on the mac.

[Scott_NewTek]

To Ed and everyone... I do read the forums when I get a chance! Things are really hopping here nowadays, as you all might guess.

I will throw out a few tidbits about the optimization process/issues we face.

We all want faster rendering. But, the fact is, there are several other areas to be optimized besides the basic render pipeline. In particular, plugins. Since very few scenes get by without some sort of plugin, it can be hard to get the kind of speed optimizations that will make a huge impact. HOWEVER! We will try!

Compilers are awesome at low-level optimization, but they can't do much for the overall algorithm, and that is where things get real complicated for a raytracer. We have a deep multi-stage pipeline that needs to be optimized. So, aside from the basic instruction scheduling and a few data typing issues here and there, or some cacheing of textures and sorting polys, etc., the whole process has to be evaluated. Especially when you look at parallelization of the algorithm. These issues are not Mac specific either. They affect the general program. We do not want (need) to produce two independant code bases just to eek out a few extra cyles on the Mac/PC.

As an aside, one of my former career endeavors was microprocessor verification. Instruction cacheing, pipelines, scheduling, etc., are very familiar things to me. :-) And that is why I LOVE the G5 architecture. It rocks! And, I will do my best to bring that power to LW!

I cannot reveal the specific optimizations/strategy to you all. That is a matter of confidentiality, as you might understand, but I can tell you that we *are* optimizing the code where possible and practical, we *are* working on fixing the bugs, we *are* working on getting the Mac glitches resolved, we *are* going to _continue_ to have a great product that all us Mac users will love. And we are going to continue to have bugs, glitches and issues, as with any software package. :-( But we are committed to pushing the envelope, not just doctoring the wounds, so enjoy the good parts, work around the blemishes, and keep positive about the future, because it is gonna be awesome!

I'll end with letting you know, I do read the forums, but I cannot devote all my time to them. Rest assured that the important issues are heard and taken into account, but that flame wars, political discrepancies, over the top requests, and hyperbole are not where I will spend my time. You want great code, right!? :-) That is where I am... when I am quiet... I am coding... :-)

My motto: "One button to rule them all!"

[hobold]

Originally posted by Scott_NewTek
Compilers are awesome at low-level optimization, but they can't do much for the overall algorithm, and that is where things get real complicated for a raytracer.You are probably already aware of the ideas presented here: http://www.openrt.de/Publications/index.html As an aside, one of my former career endeavors was microprocessor verification. Instruction cacheing, pipelines, scheduling, etc., are very familiar things to me. :-) And that is why I LOVE the G5 architecture. It rocks! And, I will do my best to bring that power to LW!
Ed, why'd you wake me up? :) Obviously, LightWave is in very good hands! With real programmers like this, they don't need armchair programmers like me.

[archiea]

Question is, is the button you are talking about F9 or ESC!?!?!!?!?:D

[mlinde]

I'm guessing he's referring to Steve's obsession with the single button mouse.

[robewil]

Or maybe the ultimate goal of reducing Lightwave's entire user-interface to a single button that reads "Make the Animation I Want".:D

[Ed M.]

Well, it seems to me that the intent would certainly seem more "wise and beneficial" if you didn't start the thread by talking as though things that are absolute matters of fact might not be true. It's a fact that Scott reads and has posted in the forum, and it's a fact that other NewTek staff review the forums as well. There is no reason to talk as though these aren't true unless your intent is to make those less familiar with the goings on in these forums think they aren't true, which would understandably then tend to make them think ill of NewTek staff. I'm not sure why you would think this is a helpful approach, let alone part of being "wise and beneficial".

Chuck, what are you talking about? I think It's *crystal* clear that I started this thread with the best of intentions. Don't try and read anymore into it than that; please. Psychology doesn't seem to be one of your strong points.

You must know by now what my intentions are and I fully expect that the MacLW users on this forum realize it as well. They want the most out of their #1 (and favorite) software application (Lightwave) that they run on their preferred platform (the Mac). The information that I post here is as accurate if not more so than anyone else's. In fact, I've gone out of my way on several other occasions to bring experts into the fold in order to open a dialogue with the dev team for Lightwave on the Mac. Chris Cox, Dean Dauger John C. Welch and a few others have all contributed what I consider to be topnotch information and knowledge. I've tried a somewhat different approach here this time in the hopes that everyone can learn something new.

On another note, I'd like to introduce everyone to my friend 'hobold'. He is an individual of high caliber. He's sharp and definitely knows what he's talking about. He's also a very humble person, but I assure you, the guy is a walking optimizer with lots of experience. Definitely one of the most intelligent people I've ever had the privilege of corresponding with online. But more than that, he's an all around good person and I've invited him here to share his knowledge of code optimization in the hopes that the tidbits he provides will allow Lightwave to shine on the G5 and provide a superior experience for the many Mac Lightwavers. Again, there was never anything more than that behind the start of this thread.

BTW, how have you been Chuck?

--
Ed

[Ed M.]

hobold writes:

Ed, why'd you wake me up? Obviously, LightWave is in very good hands! With real programmers like this, they don't need armchair programmers like me.

Armchair programmer, eh? ;) I wonder if that same term would apply to BadAndy or Chris Cox? Anyway... It would be interesting to discuss some things here in this thread though. It will give readers a good idea of what's cooking nad maybe allow them to ask questions and provide some ideas.

Thanks for taking the time time to visit us here hobold! :)

I'm glad to see Ted (eblu) here as well. The more that this thread builds, the better chance Chris, Dean, John, Dave, Scot and others will join and perhaps contribute. It could become very interesting and informative rather quickly.

--
Ed

[js33]

Ed,

I doesn't sound like you have much/any faith in the new programmer (Scott). He just got to Newtek and needs time to get familiar with the code. Give him a chance.

Cheers,
JS

[Johnny]

Originally posted by Scott_NewTek
…I LOVE the G5 architecture. It rocks! And, I will do my best to bring that power to LW!

thanks for the post, Scott..and welcome!

J

[Beamtracer]

Originally posted by hobold
You are probably already aware of the ideas presented here: http://www.openrt.de/Publications/index.html
The link that Hobold posted about Interactive Ray Tracing is interesting. It seems to be specific techniques to accelerate 3D rendering which would benefit all computer platforms that a 3D app is released on.

[hobold]

I am not affiliated with the OpenRT project (or with any other commercial, research, or otherwise significant renderer project) but I liked their ideas a lot, because they approached the problem of "fast raytracing" from the side of the hardware. Instead of starting with an algorithm, profiling it, and tuning it, they started with investigating what modern computers do quickly, what they do slowly, and how any computing problem should be shaped to exploit all strengths of the machine and avoid all its weaknesses. (Needless to say, they arrived at the conclusion that algorithms have to be arranged for high locality and high throughput.)

Of course they didn't succeed in all generality, and IMHO their specific approach leaves some recent algorithmic advances unexploited. For example they don't seem to be using "longest common traversal sequences" (which I first read about in Vlastimil Havran's doctoral thesis).

This is an optimization for the traversal of spatial subdivision structures. IMHO, it should be especially powerful when used in conjunction with "breadth first" evaluation of the ray tree (what the OpenRT folks do). The synergy should come from the fact that one needs to do voxel traversal only for a few "corner" rays, and can then use the longest common traversal sequences to infer quite a bit of information about all rays within a convex beam. If one traces, say, 4x4 rays "at once", one can often get away with voxel traversal for only the four corner rays.

Vlastimil Havran also introduces the concept of a "terminating object", i.e. an object that is guaranteed to intersect a beam of rays. So under the right conditions, one doesn't have to do exhaustive testing at all, but can infer that a number of rays must have this specific object as their "first hit".

There is yet another optimization that Vlastimil Havran leaves on the table here, because he requires the terminating object to be convex. But his scheme can be generalized to work not on geometric primitives themselves, but on the voxel cells of the spatial subdivision scheme, and those can be chosen to be convex regardless of the type of supported primitives.

Furthermore, when one extends the spatial subdivision scheme to contain the necessary information (basically, wether a voxel that does not contain surfaces is empty or solidly opaque), this opens up another optimization opportunity: shadow ray pruning. One can have solid voxels cast shadows on the other non-empty voxels. After the preprocessing, every voxel knows how it is related to each light source: fully in light, fully in shadow, or partially in light and shadow. Only in the last case one needs to spawn actual shadow rays during rendering.

Admittedly, many of these suggested optimizations make inherent assumptions that might only be true for "simple" scenes and "simple" geometric primitives. The real work is probably in applying those ideas to a production quality renderer. After all, it makes little sense to further optimize cases which are already fast. But I do believe that even a "draft renderer" with limited functionality (but beyond that of an OpenGL preview, of course) would be very useful if it achieved interactive speeds. I think this is technically within reach.

[Ade]

Originally posted by Scott_NewTek
To Ed and everyone... I do read the forums when I get a chance! Things are really hopping here nowadays, as you all might guess.

I will throw out a few tidbits about the optimization process/issues we face.

We all want faster rendering. But, the fact is, there are several other areas to be optimized besides the basic render pipeline. In particular, plugins. Since very few scenes get by without some sort of plugin, it can be hard to get the kind of speed optimizations that will make a huge impact. HOWEVER! We will try!

Compilers are awesome at low-level optimization, but they can't do much for the overall algorithm, and that is where things get real complicated for a raytracer. We have a deep multi-stage pipeline that needs to be optimized. So, aside from the basic instruction scheduling and a few data typing issues here and there, or some cacheing of textures and sorting polys, etc., the whole process has to be evaluated. Especially when you look at parallelization of the algorithm. These issues are not Mac specific either. They affect the general program. We do not want (need) to produce two independant code bases just to eek out a few extra cyles on the Mac/PC.

As an aside, one of my former career endeavors was microprocessor verification. Instruction cacheing, pipelines, scheduling, etc., are very familiar things to me. :-) And that is why I LOVE the G5 architecture. It rocks! And, I will do my best to bring that power to LW!

I cannot reveal the specific optimizations/strategy to you all. That is a matter of confidentiality, as you might understand, but I can tell you that we *are* optimizing the code where possible and practical, we *are* working on fixing the bugs, we *are* working on getting the Mac glitches resolved, we *are* going to _continue_ to have a great product that all us Mac users will love. And we are going to continue to have bugs, glitches and issues, as with any software package. :-( But we are committed to pushing the envelope, not just doctoring the wounds, so enjoy the good parts, work around the blemishes, and keep positive about the future, because it is gonna be awesome!

I'll end with letting you know, I do read the forums, but I cannot devote all my time to them. Rest assured that the important issues are heard and taken into account, but that flame wars, political discrepancies, over the top requests, and hyperbole are not where I will spend my time. You want great code, right!? :-) That is where I am... when I am quiet... I am coding... :-)

My motto: "One button to rule them all!"

Scott thank you and so to Chuck, it is good when you every now and then drop in and talk speeds and breakthroughs.
Guys hes a busy man.
I seem to rememebr Graham Devine of ID fame used to post web blogs of his breakthroughs, maybe thats whats needed here?
Just a quick mumbo jumbo slab of text that lets us know whats happening?

Plugins are a big issue, many of them arent smpt aware and if were could really speed up rendering.

[Chuck]

Originally posted by Ed M.
Chuck, what are you talking about? I think It's *crystal* clear that I started this thread with the best of intentions. Don't try and read anymore into it than that; please. Psychology doesn't seem to be one of your strong points.

That Psych isn't one of my strong suits would be puzzling news for my professors in college and grad school and a number of my employers since, but psych is irrelevant, this is just basic reading, and no "reading in" is at all needed. You wrote that Scott's presence on the forum was a rumor and that you hadn't seen any sign of him, and that you hoped NewTek would read the thread, which indicates a lack of confidence that we will. I think given the history here it should be perfectly clear to all that it is guaranteed that someone from NewTek is going to read it. What part of those items was I misunderstanding, and what good intention is involved in making other people think that Scott is just a rumor and NewTek people don't read the NewTek Forum? What was it intended to accomplish?

You must know by now what my intentions are and I fully expect that the MacLW users on this forum realize it as well.

From Beam's reply and other responses it does not appear that I was alone in my reaction to that portion of your message.

But then I guess perhaps psych might not be any of our strong suits. :)

They want the most out of their #1 (and favorite) software application (Lightwave) that they run on their preferred platform (the Mac). The information that I post here is as accurate if not more so than anyone else's. In fact, I've gone out of my way on several other occasions to bring experts into the fold in order to open a dialogue with the dev team for Lightwave on the Mac. Chris Cox, Dean Dauger John C. Welch and a few others have all contributed what I consider to be topnotch information and knowledge. I've tried a somewhat different approach here this time in the hopes that everyone can learn something new.

As I said, you've contributed greatly to the dialogue here in the past, and I do get the sense that your end aim is the improvement of LightWave on the Mac. What I find puzzling is how making folks think that a fact (we have a new Mac specialist and he reads and has responded on the forum) is a rumor and think that NewTek staff do not read the forums would contribute to that goal? I'm more than willing to presume good intent, I'm just perplexed as to how that fits in to it.

[mlinde]

Originally posted by Chuck
But then I guess perhaps psych might not be any of our strong suits. :)

Hey! I paid a lot of money to have one of my B.A degrees say Psychology on it!

Unfortunately, the printed medium doesn't easily convey intent and emotion, without a LOT of time and text. I think that regardless of the intent, now we all need to come together and sing koombyha.

As people interested in the future of the Macintosh platform, we all have our personal stakes or issues with what is going on. What we need to realize is that everyone is trying to move forward. However, in any endeavor, sometimes that progress is slow, and sometimes it has setbacks. Everyone go watch the sunset tonight (or the sunrise tomorrow, if it suits you). This place is turning into a cage match at the ultimate fighting championship, when it should (at worst) be a town meeting.

[dmg3d]

Originally posted by Ed M.
OK, apparently there is a new Mac programmer on NewTek's Mac dev team. This fellow has been rumored to have contributed to the MacLW forums on occasion - regrettably, I missed those posts....
Hopefully someone at NewTek reads this.


FWIW, when I first read Ed's post, my take on it was Ed was aware of a new programmer, but not his name (although I think "rumored" was a poor choice of words, since he could've done a search).

And while I'm thankful that people at Newtek read the boards, I don't expect them to get involved in every discussion... or even read EVERY thread to see if there's something that they can offer their take on. (although Ed's subject line WAS kind of a flashing red light :) )

-Dave

[Scott_NewTek]

Originally posted by dmg3d
And while I'm thankful that people at Newtek read the boards, I don't expect them to get involved in every discussion... or even read EVERY thread to see if there's something that they can offer their take on. (although Ed's subject line WAS kind of a flashing red light :) )

-Dave

Exactly. If I had a bell sound go off for every message posted in the Mac forum I would hear a constant ringing!

I saw that red light...

-Scott

"One button to rule them all!"