PDA

View Full Version : New LightWave LINUX ScreamerNet Modules



Kurtis
03-21-2005, 10:47 AM
NewTek has made available two new revisions of the LINUX ScreamerNet module for LightWave 3D. As with the previous LINUX ScreamerNet module, NewTek is making these modules available as a service to the LightWave community at large, but we are not able to offer direct Technical Support for them. There are a number of resources on the web for public support, including the LW - ScreamerNet (http://vbulletin.newtek.com/forumdisplay.php?f=158) portion of the LightWave forums.

The new revision of the module for LightWave 7.5d can be accessed from the LightWave Downloads page (http://www.newtek.com/products/lightwave/downloads/index.html).

The new revision of the module for LightWave [8] version 8.2 can be accessed by registered owners of LightWave [8] through the Product Registration site (http://register.newtek.com/).

Alliante
03-21-2005, 03:10 PM
Fantastic!

Thank you for keeping Linux awareness alive!

polarbear53
03-21-2005, 10:11 PM
Are there any speed differences? Does linux have less overhead? Are there any pros to linux? Just wonderin'

kevman3d
03-22-2005, 04:48 AM
Linux SNII may appeal but be aware that you may find yourself in trouble trying to render with 3rd party plugins that have been compiled for either Windows or OSX...

Though an alternate solution that seems to work (apparently, according to people who've tried) is to run the windows LWSN.EXE under WINE for Linux as it apparently works great, just a little slower then natively under Windows...

Other then that, nice to see they're back and available again... :)

Johnnyx
03-22-2005, 03:03 PM
..can't wait to try this out.. I'm registered with NT Europe... do I download from there?

Phil
03-22-2005, 07:15 PM
Linux SNII may appeal but be aware that you may find yourself in trouble trying to render with 3rd party plugins that have been compiled for either Windows or OSX...

You certainly will. Unless you are using only those addons that have come with LW or (probably) LScripts in your projects, you will be unable to utilise these linux-specific builds. From previous experience, linux LWSN is still only available for x86 so PPC linux folks will also be out of luck.



Though an alternate solution that seems to work (apparently, according to people who've tried) is to run the windows LWSN.EXE under WINE for Linux as it apparently works great, just a little slower then natively under Windows...


Yep, although you will need to run X11 on your nodes due to Wine requirements. That's slightly irritating, but you only really need a bare bones X11 server and a terminal to run the LWSN program from. You don't need to run GNOME or KDE, etc.



Other then that, nice to see they're back and available again... :)

Absolutely. I'm really hopeful that a Wine-based 'port' of LW for linux will appear before the end of the year.

doimus
03-23-2005, 07:41 AM
Are there any pros to linux? Just wonderin'

Polarbear, Linux is at least infinatelly cheaper than windows, and that's something to consider when building render-farms etc...
Also there are other pros to Linux, but that's nothing to do with LW... You should really check specific Linux related sites/forums for general benefits Linux has to offer over Windows... that sort of discussion often sparks a flame so it's better not to touch it here, really ;)

Phil, I hope they put out a full (ie. not-Wine) Linux version, after all LW is not that much tied to the OS it's running on...

mgrusin
03-23-2005, 12:19 PM
Has anyone made or seen any "Live-CD" - type Linux distros for these things?

Seems like a good idea to me, it would allow anyone to make "instant" temporary (or permanent) rendernodes, just boot the CD on a spare machine. My Linux knowledge is limited at best, but if nobody else has done it I'll look into it and see how practical it might be.

And thanks, Newtek! :cool: -MG.

Maarten Welzen
03-24-2005, 01:46 PM
Hoe does the native linux screamernet node perform on a same machine compared to XP?

BeeVee
03-25-2005, 05:17 AM
Users registered with NewTek Europe can download the i386 RPM for the Linux Screamernet node from http://www.newtek-europe.com/uk/support/download.html

B

blackbox
03-25-2005, 07:16 PM
Has anyone made or seen any "Live-CD" - type Linux distros for these things?

Seems like a good idea to me, it would allow anyone to make "instant" temporary (or permanent) rendernodes, just boot the CD on a spare machine. My Linux knowledge is limited at best, but if nobody else has done it I'll look into it and see how practical it might be.

And thanks, Newtek! :cool: -MG.


Hi mgrusin

I've just compiled a Live-CD with the screamernet.
Actually I made it with knoppix remastering instead
of re-inventing the wheel by making a Live CD from
scratch.

Have to wait until Monday to try out this thing as I
will have access to one of my sch lab.

Will let you guys know how it goes. :)

- Vincent

mgrusin
03-26-2005, 09:32 AM
Way to go Vincent! :cool:

Thanks for doing this, definitely keep us posted on your progress.

-MG

watsondk
03-27-2005, 03:57 AM
Hi mgrusin

I've just compiled a Live-CD with the screamernet.
Actually I made it with knoppix remastering instead
of re-inventing the wheel by making a Live CD from
scratch.

Have to wait until Monday to try out this thing as I
will have access to one of my sch lab.

Will let you guys know how it goes. :)

- Vincent

very interested in seeing this

all my attempts at getting the new modules to do anything have ended up with segfaults, and thats after driving screamernet manually to get around the cross-platform path translation nightmare.

so far I have tried various kernels, CPUs, etc, all with the same result

still investigating the causes, if I find anything useful will post here

Update: Seems that the segfault is coming from lcore8.so or one of its dependencies. The strange thing is it only happens if I try and render a scene that includes subpatched objects.

I tried, all sorts of different shapes, subpatch levels, sizes etc, all with no effect. Then moved onto the Linux installs, 2.4/2.6 kernels, different physical boxes with different CPU, enable/disable HT, memory size, lcore8.so dependancy library versions, linux distributions (Gentoo, Slack, RH)

None of this made any difference

bug maybe?

Phil
03-28-2005, 06:05 PM
Phil, I hope they put out a full (ie. not-Wine) Linux version, after all LW is not that much tied to the OS it's running on...

The problem is not with LW in itself. It's the plugins, commercial and otherwise, and support issues that are significant.

The problem with a native port is that, as the Mac folks discover, developers still primarily develop for Win32. Unless a compatibility layer could be introduced to allow Win32 plugins to be used with a native port on x86 linux, NewTek would suddenly be launching a product with no 3rd party plugin availability or support and face an uphill battle to get market share and recoup their costs. Developing such a compatibility layer would rely on LW architecture being sufficiently flexible and would also take developer time away from other issues. Once demand is better known, a decision about a native port could be made and 3rd party support would be more likely. After all, how many of those clamouring for a linux port will put cash on the table for NewTek and the various 3rd party plugin vendors?

You also need to factor in that 3rd party developers may not be able or willing to support multiple markets - an issue more apparent with compiled plugins than LScripts in the main - by having to maintain Win32, Win64 (eventually), Mac and Linux. Of all of these, linux will have the smallest market share for a native port and it's the one that will be naturally neglected. A Wine-based port of LW makes better sense in that it won't impose larger support issues (in general) that Win32 for developers.

Remember that, unless a developer is feeling particularly generous, any commercial product that they have sold for Win32 will need to be relicensed for linux to recoup their development and support costs. Are you and others prepared to pay again for the same product to run under a different operating system?

I'd love a native port, but I would suggest that small steps would be far better and Wine be used to full advantage for all concerned.

Phil.

Salv8or
03-29-2005, 04:51 PM
Does the SNII for linux, support pvm (parallel virtual machine)?

I have long wanted to make a cluster render machine, much coz its cheap to by alot of semi-fast cpus and mainbords equipped with a fair amount of memory and have them share, rather then to by a fast computor with lots of memory.

(besides it would defenetly look cool) =)

And you can always use all youre old computors, without upgrading all of them with alot of memmory.

//Salv8or

tischbein3
03-30-2005, 09:22 PM
The problem is not with LW in itself. It's the plugins, commercial and otherwise, and support issues that are significant.

Phil.

I didn't wanted to say something about this, because I primary think, it is more important to progress other lw issues first... But I do not agree with your arguments. I think its a lot more complicated.

This post is a bit longer than I usally write, but its something I had to write down.
Sorry for this.


Pro linux version:

Acceptance for a linux port is not only based on the price... In fact you cannot predict it: Its a question of support, the amount of users actually using linux, and how far they are experienced with it.
(Well explaining someone to cope a fictious lw version wich do not even understand the "dongle concept" would'n be so funny, I think)

Porting screamernet is a step in the right direction, NT used the minimal development energy to show interrest and to test acceptance, and to get 3rd party developers onboard.

but it somehow it failed, I don't know why, but I do have made some thoughts:

1. First its lazyness: "Oh my good I do have to install linux..." (wich often do mean: I have to repartition the harddisk and invest at least one day for installation)" .....AND setup the network...i will do this later...."

Second its fear: Fear of installing linux, getting the development system running (if you are developer), and setting up a network across two different OS.

First is a question of time, and like the second: a question of information:

if there would be a plain installation guide on this web page, (really does not need to be that specific informative, but more to calm down fears) acceptance could instantly rise. (or not, I'm sometimes really bad in those "customers predictions")
The same with the sdk: A step by step compillation guide for linux (its gcc isn't it ?) would made it more interresting for porting its plugin. (Hey, it's more cool to have a windows and a linux version of a plugin aviable. than only a win.)

2.Others also ported their applications. I do not know their market sales, but because they DO provide new versions, market situation can't be that bad.

3.Cross upgrades always existed, and the price was also accepted. if I would follow your logic, as an owner of a Duo version, I've paid the development of two systems.... (Can I get the money back for one of it, to make it undone ? ;) )

The last argument is a bit emotional and not that reasonable:

4.Its somehow confusing to see a company wich had been self sufficently ported lw on a lot of systems, suddenly fears the step to a new one...


Against:
1. Don't expect that IF there is a LWlinux it will be running on a free or low cost distribution... Today a lot of people are paying a lot of money for certified distributions:
meaning high priced packages wich are only certified to run certain software. Using free disributions is either not possible (refuses installation) or do not provide you with support.
(Hopefully this will be only a trend and NT will never follow it....)

2. Co-Soft. Ok, its getting better, but most people do not only have LightWave installed, but at least half a dozend other applications: video / 2d graphic editing etc... so a lot of the people here are forced to switch between OS because there is no linux alternative. (I said its getting better, but its still an argument)

3. A linux version do need manpower wich could be invested somewhere else.


so again sorry for this long and lousy written post, but just my 2 cents on this topic.

Phil
04-05-2005, 07:38 PM
I didn't wanted to say something about this, because I primary think, it is more important to progress other lw issues first... But I do not agree with your arguments. I think its a lot more complicated.

This post is a bit longer than I usally write, but its something I had to write down.
Sorry for this.


Pro linux version:

Acceptance for a linux port is not only based on the price... In fact you cannot predict it: Its a question of support, the amount of users actually using linux, and how far they are experienced with it.
(Well explaining someone to cope a fictious lw version wich do not even understand the "dongle concept" would'n be so funny, I think)


As I said, it's about the availability of all of their current LW toolset for current users. Price is a small issue in that light. I for one wouldn't jump to a native port if I couldn't use any of the toolset I have invested time and money in - it wouldn't make sense. A Wine port solves that (largely) and will allow all concerned to evaluate the demand for a 'proper' port.

Using Wine to provide a commercial product on linux using Win32-based code doesn't make it any less of a product. The arguments against using it being largely 'religious' although wine(lib) does have some issues over the reliability of certain releases, I grant you.



Porting screamernet is a step in the right direction, NT used the minimal development energy to show interrest and to test acceptance, and to get 3rd party developers onboard.

but it somehow it failed, I don't know why, but I do have made some thoughts:

1. First its lazyness: "Oh my good I do have to install linux..." (wich often do mean: I have to repartition the harddisk and invest at least one day for installation)" .....AND setup the network...i will do this later...."


Nope. It's a question of invisible demand and the above noted reason that I, for one, cannot use them. There is no ability to use the Win32 toolset. Unless you bring the developers with you, you will see no uptake (or very minimal). Wine(lib) eases that considerably and allows you to convince 3rd party developers that the effort involved in developing, testing and supporting an additional port of their work would be worthwhile. Remember that many plugin developers are (very) small companies with, at most, a handful of people. Any additional cost is unwelcome in this situation - LW plugins are a very small revenue stream for most who try to license them.



Second its fear: Fear of installing linux, getting the development system running (if you are developer), and setting up a network across two different OS.


I doubt it. Installing a mainstream linux distribution is easy - my wife can do it without assistance and she's as far from a technical person as can be. As for development systems, last I knew there was next to no information for the SDK under linux environments *shrug* Even if there were, would you expect a lone plugin author to go to all this effort for near-zero uptake, even if he were to request additional fees from his customers? There would be no uptake as each customer would need the rest of their toolset to be made available as well.



First is a question of time, and like the second: a question of information:

if there would be a plain installation guide on this web page, (really does not need to be that specific informative, but more to calm down fears) acceptance could instantly rise. (or not, I'm sometimes really bad in those "customers predictions")
The same with the sdk: A step by step compillation guide for linux (its gcc isn't it ?) would made it more interresting for porting its plugin. (Hey, it's more cool to have a windows and a linux version of a plugin aviable. than only a win.)


There is an issue over lack of information for developers with linux. From the last information I had, developers were finding it impossible to locate information / compile with GCC for some reasons. I'm sure someone pointed out that the current package from NT was compiled so that it should be possible for others to work with it, but maybe NT forgot / has yet to release the documentation they have about the process.... *shrug* Developers shouldn't have to fight to find this stuff so will naturally drop it and head back to Win32 for this and the financial reasons noted above.

A native LW port would probably solve this problem, but unless developers come along for the ride, it's likely a pointless endeavour.



2.Others also ported their applications. I do not know their market sales, but because they DO provide new versions, market situation can't be that bad.


Yes, it can. The LW plugin market has been soft for a while. LW in itself last had a foothold on *nix back before 6.0 came out. NT walked away from the Sun and SGI implementations, for example. If they had been popular, they would have stayed around.

The comparable applications (Maya, XSI, etc.) have roots in *nix so it was never a case of entering a market without having knowledge about the revenue stream. Coming from *nix to Windows is always going to be a move of very limited risk just due to the difference in size of potential market. Taking developers of addons is therefore an easy job by comparison - lots of upside, very little downside. As these applications were also (then) very expensive, addon vendors could charge whatever they felt appropriate to cover costs - the LW market won't take this.



3.Cross upgrades always existed, and the price was also accepted. if I would follow your logic, as an owner of a Duo version, I've paid the development of two systems.... (Can I get the money back for one of it, to make it undone ? ;) )


That's not entirely true. The Mac version has generally been supported by the revenue from the PC version due to the large difference in the size of the user base. What you also find is that the Mac version tends to get plugins long after the PC version - again because developers have to get hold of a Mac to put the code together and test it. LScript mitigates this, but has problems that cause some to go the native code route. A linux port would come lower in priority again, I suspect.



The last argument is a bit emotional and not that reasonable:

4.Its somehow confusing to see a company wich had been self sufficently ported lw on a lot of systems, suddenly fears the step to a new one...


It doesn't, rest assured of that. The issue is not that simple when it comes to sinking a large amount of time and effort into something that may not payoff.....the risks have to be evaluated and managed. I maintain that Wine is a perfectly acceptable first step. Small steps.



Against:
1. Don't expect that IF there is a LWlinux it will be running on a free or low cost distribution... Today a lot of people are paying a lot of money for certified distributions:
meaning high priced packages wich are only certified to run certain software. Using free disributions is either not possible (refuses installation) or do not provide you with support.
(Hopefully this will be only a trend and NT will never follow it....)


I'm not sure I follow this. Gentoo, for example, causes lots of support problems for a good many commercial and other vendors, simply because people enable all kinds of options, etc.

Windows and OSX provide a (largely) predictable baseline from which to work on support problems. Drivers, etc. complicate matters, but that's essentially the only deviation point. It's relatively easy to sort technical issues out. In that sense, suggesting that a few 'predictable' distributions should be supported is reasonable. I'd rather they hired more developers than distro-specific tech support guys.



2. Co-Soft. Ok, its getting better, but most people do not only have LightWave installed, but at least half a dozend other applications: video / 2d graphic editing etc... so a lot of the people here are forced to switch between OS because there is no linux alternative. (I said its getting better, but its still an argument)


Yep. As such, again, a Wine port at this time makes more sense. It reduces risks to a minimum and allows you to evaluate the potential.



3. A linux version do need manpower wich could be invested somewhere else.


so again sorry for this long and lousy written post, but just my 2 cents on this topic.

It's not lousy, but I just think you are missing the considerations that must be applied when talking about a commercial product that provides a great deal of NT's revenue. It's a large part of the company AFAIK and with the increased competition from the likes of XSI and Maya, careful handling is required to avoid a major problem. The main markets remain Windows and Mac - anything else shouldn't pull resources away from them without good reason.

#lwrs_web
04-06-2005, 05:03 PM
Hi mgrusin

I've just compiled a Live-CD with the screamernet.
Actually I made it with knoppix remastering instead
of re-inventing the wheel by making a Live CD from
scratch.

Have to wait until Monday to try out this thing as I
will have access to one of my sch lab.

Will let you guys know how it goes. :)
- Vincent

Any news? A Live CD would be cool.
Even better: make it run on a openMosix Cluster.

Quick plan:
- Master node running ClusterKnoppix (with lwsn installed)
- add CHAOS nodes from CD/Network Boot Image (6MB)
- lwsn is installed only on the master, processes are distributed on the master by the load-balancer
- no code change needed


Check this video:
Presentation :: SSI (Single System Image)
http://itsecurity.mq.edu.au/papers/auugss04/SSI-Security-sml.wmv


How To Create Movies on Your openMosix Cluster
http://www.openmosixview.com/makemovie/

Example files using PovRay Renderer
http://www.openmosixview.com/makemovie/makemovie.tar.gz


Running ClusterKnoppix as a master node to a CHAOS drone army
http://itsecurity.mq.edu.au/papers/How%20To%20-%20Heterogeneous%20Clusters.pdf

ClusterKnoppix
http://bofh.be/clusterknoppix/

CHAOS openMosix cluster distribution
http://itsecurity.mq.edu.au/chaos/about/index.htm

tischbein3
04-08-2005, 12:35 PM
Phil, now you deconstructed my arguments quite well.....


About different linux versions:
Of course there is no reason against exclude "trouble maker" distributions.
I was concerned about the so called "enterprise"-editions wich make the biggest argument for using linux close to "useless". So I should have be more carefull in explaining it:

An example, is this quite famous triology (I'm not a fan of it). You can read a lot about the "linux success storyx behind it" on many linux site, but quite less the about the other side:

http://www.biohabit.org/node/654

I do agree in almost 90% of your arguments, but with different strengths, so argue against or for them, would definitive lead to nothing....

So as a result, could we agree on:
"Newtek should invest the 2-5 hours in updating the sdk documentation for linux development as the next (small) step." ?

Phil
04-13-2005, 07:22 PM
Phil, now you deconstructed my arguments quite well.....


About different linux versions:
Of course there is no reason against exclude "trouble maker" distributions.
I was concerned about the so called "enterprise"-editions wich make the biggest argument for using linux close to "useless". So I should have be more carefull in explaining it:

An example, is this quite famous triology (I'm not a fan of it). You can read a lot about the "linux success storyx behind it" on many linux site, but quite less the about the other side:

http://www.biohabit.org/node/654

I do agree in almost 90% of your arguments, but with different strengths, so argue against or for them, would definitive lead to nothing....

So as a result, could we agree on:
"Newtek should invest the 2-5 hours in updating the sdk documentation for linux development as the next (small) step." ?

Yep, that would be a good step. I'm very positive that they are seriously working on this, but possibly with a less focussed push than nailing all the issues with the current code base.
It probably wouldn't hurt if interested developers would make a represention to NT with the issues they are encountering in supporting the current native LWSN port, though. It's really up to them to draw NT's attention to the problems they have with the toolkit they are being asked to use, after all.

Bear in mind that NAB and SIGGRAPH should hopefully show where NT is heading and whether those wishing to use LW on linux will continue to have to resort to dongle cracks to use the software that they purchased under Wine. FWIW, I have so far found that the January 2005 release works best for LW.