PDA

View Full Version : Game tools for LightWave



Kurtis
07-06-2005, 08:38 PM
Can anyone here fill me in on any 3rd-party plug-ins, LScripts, converters, apps, etc. for getting LightWave into games or vice-versa?

somnambulance
07-06-2005, 09:20 PM
I use the LW2DTS (http://www.gnometech.com/) exporter for Torque, works on both PC and Mac.

I have yet to use it, but here is a link to a Doom 3 engine LW2MD5 (http://www.doom3world.org/phpbb2/viewtopic.php?t=4595) exporter. If your going to be using the Doom 3 engine, you will need the normal map plugin for LW as well which you can find here (http://amber.rc.arizona.edu/lw/normalmaps.html).

somnambulance
07-06-2005, 09:23 PM
What do you have up your sleeve?

interNEKO
07-07-2005, 11:13 PM
I have been recently experimenting with D-Storm's DirectX file exporter. I recently started a thread about my findings on these forums HERE (http://vbulletin.newtek.com/showthread.php?t=38074)

I will soon be updating it with information concerning the different animation types that directx uses and what this plug-in can produce. Besides that, go for Polytrans, but it costs about $500. However, it can do everything.

Silkrooster
07-07-2005, 11:29 PM
This thread sounds interesting. I am just learning or relearning several programming languages. I would love to see more interaction between Lightwave and gaming engines. Adding a direct X exporter would be a step in the right direction. How about adding feature set to the SDK and Lscript to create prototyping games in Layout. Sorry I am getting carried away here. :dance:
Silk

Lamont
07-08-2005, 04:57 PM
UT2k4/UT2K3/Quake - Michael Bristol - http://www.troggpond.com/lwtools/index.html
Torque - http://www.garagegames.com/
Ogre 3D - http://www.ogre3d.org/
HL2 - http://forum.resistanceandliberation.com/showthread.php?t=806
Direct X (DStorm)- http://www.dstorm.co.jp/english/plugin/object.htm#DirectX2
Ska Tools (Serious Sam) - http://files.seriouszone.com/download.php?fileid=400
A4 Engine - http://www.greenbriarstudio.com/3D/

Silkrooster
07-08-2005, 05:51 PM
Thanks for the links, I had to store them in favorites for now. I am just getting back into programming. It's been years. :( Boy has things changed.
Silk

turbo
07-09-2005, 05:00 PM
heh.. just found this thread.

We have been using:
- Torque Game Engine, DTS Exporter, Show Tool Pro
and will be getting Constructor as soon as it is finished.

(we'll be switching engines in near future)


I must add that we have been using the first two for probably a couple of years now.. The games we are making are for mac, windows and linux simultaneously.

Here's a quick link (http://www.gnometech.com/forums/showthread.php?threadid=70) to a couple of screenshots of in game examples. Please note that the textures are unfinished placeholders as are some of the primitive objects, but you can see everything is working nicely.

Ideally it would be awesome to have a dif exporter for lightwave.

Kurtis
07-16-2005, 07:11 AM
Thank you all for your replies. I apologize for taking so long to respond.

Nothing up my sleeve. This is a personal interest question, not an official request from NewTek.

Silkrooster
07-17-2005, 12:52 AM
We forgive you this time. :D
Silk

doimus
07-21-2005, 09:02 AM
But Newtek should really check out independent/free game engines and provide at least some support or good will in general.

Check out OGRE 3D - certain other company is already supporting them... :hey:

Whit
07-21-2005, 10:38 AM
LightWave provides support for Shockwave. There are a lot of nice things being done with ShockWave (not a free development environment).

Take a look at:

<http://vbulletin.newtek.com/showthread.php?p=284660#post284660>

for information about a simple way for LightWave users to create an interactive Car game.

--Whit

Silkrooster
07-21-2005, 03:26 PM
There is no way that Newtek could support all game formats. It would be better to see layout being use to create prototyping games by expanding lscript or another language. Then make the lws file format open to the general public or another file format, this then can be used by all game engines to use lightwave objects in a scene created by lightwave with perhaps a seperate text file with the code in it to make it easier to transfer to the game engine.
Not sure why, but I can see this happening if lightwave supported c++ and directX file format. Probably because I have heard more about those than any other. But if lightwave exported the entire scene as .X and the prototyping was done in c++, then I beleive all you would need is the header files for a game engine. Making it easier for you to write your own game engine. If there are parts of the game engine that you do not know how to write, you could purchase a game engine sdk.
So the question is does the .X file format support all the features of lightwave?
Silk

doimus
07-21-2005, 03:44 PM
I agree about LW not being able to support all of the currently available engines.
Doing something like that would be pointless waste of Newtek's resources...

It's just the will to cooperate thats needed on Newtek's part.. and that probably brings us back to the omnipresent issue of opening-up-the-SDK(TM).

jeffb
07-22-2005, 07:09 AM
It's just the will to cooperate thats needed on Newtek's part.. and that probably brings us back to the omnipresent issue of opening-up-the-SDK(TM).

You are probably correct in this. One of the things that makes MAX such a widespread tool among game artists is the ease of use between that and most game platforms that use DirectX. MAX allows artists to view EXACTLY what models look like and how they move in the actual game platform without having to export out. This makes changes simple. No exporting, no third party weirdness; model and animate as normal and see what the results are real time. Its very simple.
Of course, its helps that many of these game engines have direct import/export from MAX. This tremendously decreases errors and hence time.

Myagi
07-22-2005, 08:55 PM
an overhaul of the SDK would sure be nice, but until then there are a few pretty simple (to implement for newtek) features that would make life a bit easier.

For example just something simple like being able to add custom data chunks to an object (either completely user defined binary chunks or some simple tag-value pair based thing), which gets loaded and saved inside the lwo. With the nature of the lwo format it should work fine and not break any compatibility. It would be nice to be able to "bake" certain game specific info into it, elegant and clean, and also useful for various (modeler) plugins where you'd like to store object specific settings along with the file.


In general I'd like more help-developers-help-themselves features that are easy for newtek to add but save a lot of time, rather than any features/tools for specific engines.


but it's all hypothetical since it was a personal request and not on behalf of newtek :)

interNEKO
07-24-2005, 07:59 PM
I am going to be updating my other thread soon, but what I have seen so far from D-storm's x-file exporter is good. It does nice surfact to material translation and animation key generation. I am now starting to test out skinned mesh generation with it. The D-storm plug-in also has a viewer tab, so you can launch a program to view the exported file. Certainly not as nice as having it in the app, like it was mentioned Max reportedly does.

Direct X comes with a ton of helper functions and classes to load and animate from X file formats. Most game studios end up using their own proprietary formats anyway, which is probably why NewTek is not trying to specialize in any particular set of exporting options.

NewTek does need to understand that a ton of independant and hobby game developers use the X-File format because of the SDK's support for it. Many DirectX books use the format also since it is supported by MS. If NewTek officially supported the exporting of X-Files, then they would get an automatic big applause from the game dev community, which WILL lead to a lot of sales. Right now TrueSpace is mentioned most in gamedev books because a good supply of plug-ins exist for it, and it was the package I was previosly using.

iaef
07-27-2005, 01:40 PM
Well, maybe NT is not really looking towards the MS path, because it might certainly cost them some kind of license. But this is just a guess.

About the comment for including user defined data, I have already got that one answered. I can't remember who, but someone told me that they used this to make their own game. LWO extensibility nature makes it possible, so maybe there is just a simple script that could accomplish this key value pairs trick, or to get into the LWO come binary encoded data. I remember also that this person told me that they used simply lscript to make simulations on layout, so they could see how the game was going to come out. I remember it had something to do with traffic simulation, and it was for a crashing racing game for the xbox, and their production line was based on :lwicon: .

BeeVee
07-27-2005, 02:51 PM
http://www.newtek-europe.com/uk/community/lightwave/lake/1.html

say no more... :)

B
PS Apart from the fact that Burnout 4: Revenge is using the same pipeline...

Dodgy
07-27-2005, 04:07 PM
You could use a custom shader and store your object details in there, either in the form of an lscript, or a c based plugin. For your scene data it's even easier to add any type of functionality for gaming using lscripts or plugins.

Myagi
07-27-2005, 05:54 PM
About the comment for including user defined data, I have already got that one answered. I can't remember who, but someone told me that they used this to make their own game. LWO extensibility nature makes it possible, so maybe there is just a simple script that could accomplish this key value pairs trick, or to get into the LWO come binary encoded data.

are you sure it was possible from within LW (modeler, and without "shader-hacks")? I could see how might be able to add custom chunks to an LWO with your own external tools (but would those "stick" to the file when loaded/saved by the modeler at a later time?), but I haven't seen how that would be done from within LW/plugin.

I don't currently have an urgent need for it since I worked around it in other ways, my post was just "triggered" by the fact that these workarounds (that take time to do) could have been avoided by very simple means.



You could use a custom shader and store your object details in there, either in the form of an lscript, or a c based plugin.

Sure, but that's an ugly hack, and just takes more time to code, easier to break, than built in support. The idea of my post was what could be done by newtek (with little effort) to make it easier for game developement, not that you can't do various hacks to work around the limititations. Thanks for the suggestion though :)

Knight Chat X
07-29-2005, 04:01 PM
For gaming they should just simply support DirectX .X File exporting by default.

Given they also properly export all animation, material, texture, and .fx shader/effect information, and give some up-to-date examples of how to import the exported animation back into a custom DirectX application in VB.Net it'd kickass. :lwicon:

:tongue:

iaef
07-29-2005, 11:02 PM
Reading Modo help, in the first sections, where File menu is explained, in the section of import export formats, they explain that LWO format is extensible and that you could insert your own data chunks, and Modo and Lightwave will respect them and they would be forward compatible. They also explain that maybe third party applications might wipe this kind of info out. Things to take into account on a workflow.

On the other side, I believe that maybe from Modo there is a way to put in info, because there are functions that help for this on their scripting language. It would be great if there could be such funtions on :lwicon: . I don't know. Later if I have time, I will check SDK to look after it. Or maybe, somebody knows and might share this knowledge. :help:

interNEKO
07-29-2005, 11:54 PM
The major problem is, the only people that have the resources to make their own custom plug-ins, lscrips, etc, are companies who have the people to do this for them. At that point, they are most likely using their own proprietary engines.

Perhaps Newtek doesn't care about people using their software for games, and only animation. I hope this is false by the fact this forum existing. Because they seem to want people to use their software for game making, they MUST start supporting exportation to "popular" formats. The major formats are Quake(MD3/4?), HL and DirectX. They should look at what is out there in free plug-ins, adopt those that are already useable, and try to develop what is not great.

While looking for DirectX plug-ins, I have found lots of MD3 and HL solutions. This covers the mod'ing community already. Great, but that does nothing for the hobby/pro game dev comunity, which this forum seems to be about.

People who use 3rd party engines, like Torque, seem to have plug-ins that the designers of Torgue create (correct me if I am wrong). However, besides the Quake and HL engines, the others are an extremely small subset.

Some might say it is on MS's shoulders to make a DX plug-in, but since it is just a graphics API, and not an engine per-say, it goes back to NewTek. Again, I have to stress the amoung of Game Dev books and resources out there that use the Direct-X format. Maya and TrueSpace seem to be the leader for plug-ins, and as a result, are getting much more attention because of their Direct-X support.

I only wonder if any Newtek employees read these forums. I know for a fact their support is lacking since I never got help, or even a reply, with my dongle issue. :grumpy:

Knight Chat X
07-30-2005, 01:37 AM
You have an important point there.

All these years have gone by with DirectX out and I still don't see a main stream professional graphics development program supporting DirectX format exporting for games aside from Gamespace, DeleD, and a few others, the more expensive software rely heavily on other's developing the solutions for them, weither by exporter plug-in's, or by the recommended use of other programs/converters or game engines.

Personally, I do not want to use another game engine, it's easy enough now to just make your own game engine.

Even Maya is lacking at this point, 1 thing that brought me back to Lightwave was the fact Maya failed to export material and texture information, the texture names were blank, and not only that, the generated .X files were much bigger in size and contained duplicate templated code blocks, the box should have been 2 - 4KB in size, it was 13 - 14KB instead, very big difference if you render more complicated geometry, then the Kilobytes really begin to add up. The main point is, it just didn't work, I spent a few days trying to get a method worked out and it ended up being to use another program altogether, or re-invent the wheel and do the texture, material, and shader/effect .fx applications myself in code, the 2nd method would take way too long and could be too error prone, so instead, I switched to Lightwave, and literally within a 11 or so minutes after installing an .X File exporter plugin managed to get a successfully textured box exported. Yippy!

interNEKO
07-30-2005, 10:25 AM
That's good news. Can I ask which X-File exporter you are using? I am using D-Storm's, but it crashes the app now and again. Again, I have seen a growing number of game dev books on the shelves that support Maya. If they are using that crappy exporter you are using, and can get people to write game books using their software, just imagine if Newtek produced a half decent one..

Knight Chat X
07-30-2005, 01:22 PM
Right now D-Storm, works like a charm.

Myagi
07-30-2005, 05:34 PM
The major problem is, the only people that have the resources to make their own custom plug-ins, lscrips, etc, are companies who have the people to do this for them. At that point, they are most likely using their own proprietary engines.

I'd have to disagree, small devs/companies that don't have the money to license expensive engines often end up in the do-it-yourself situation, writing their own tech, and that includes all the tools (including exporter plugins). This is why I'd like to see improvement in the areas that make it easier to create those tools, because when you do your own tech you mostly need customized formats and tools. (And the easier it is to create those tools the less of the resources you mention above are needed.)

This doesn't mean there can't also be more exporter plugins out of the box with LW. Having worked at several (very) small developers and now doing my own thing I'm, of course, heavily biased towards what would have made (or will make) a difference to me/us, and lack of out of the box export formats was never an issue.

interNEKO
07-30-2005, 08:42 PM
Perhaps my sentence was a little confusing, but what you said is exactly what I mean. I wasn't trying to say only huge game companies have the money to produce their own plug-ins, and as you mentioned, small companies that don't have the cash to license big engines, end up making their own, which of course means a custom exporter. However, that takes time. Not just to develop it, but to maintain the exporter as the engine develops more, and aquires new features. This becomes counter productive to small teams because they are now spending man-hours on maintaining and developing an exporter. This is where common formats MUST be used, which include .X files and others like MD3.

Then you have the next level down of 'hobby' game programers who just want to make something. They don't have the knoweldge, man power, or time for worrying about exporters. They will choose the modeler that will allow them to easily create something, and be able to save it to a format that they can already use.

It seems like we are all in agreement here, so I am not going to try to make anyone angry by going on my stupid rants. I am just happy there is a place we can all tell each other the solutions we have found. :)

Knight Chat X
07-30-2005, 09:32 PM
Writing a plugin has nothing to do with money it's choice and neccessity, you don't need to write a plugin to begin with if that desired or needed functionality is already included in the main software package, as a software developer, I'd rather not waste my time writing portions of uneccessary code, I do it all so I have very little time to spend on complications these days, I wanna focus on my development and productivity, my application, and I want it simple and straight forward with as little headaches as possible. It can be done.

I'll give you an example of the problem if it were bigger, let's say we just remove all export functions from the program period, no 3rd party interaction. That would be taking a step backwards not forward. Now what?

You can do all the modeling, animation, rendering, you name it, but ya can't save any form of output. Think about that a second.

Ok, so we got game engines other people made, which makes our licenses and features limited to an extent on what the game engine developer provides, unless you can re-compile the source code yourself or make modifications and it's not under some kind of GPL license, some free, some over expensive, you are now relying on 3rd party dependancies, and as more and more plugins and misc. updates and add-ons are required to add functionality that was lacking in previous versions, that's a pain to manage.

Enough insanity.

A custom file format is just that, a custom file format, pretty much anyone can do it, but that's besides the point. I don't wanna install another bulky SDK or be required to implement another custom user defined script or go into depth of learning file formats, when that happens you must provide more dependancies and more information and thus there are more things to learn, more and more standards, more problems and less solutions. Lighten the load.

Regardless of weither you use MAX for viewing models or not you can already do that using Mesh Viewer, of coarse if you use OpenGL that's another case and is yet another standard, and again MAX is a 3rd party product.

There needs to be better bridges to close these time wasting gaps. Back in the days it was great using Quake3 engine models, it made things a bit more organized, but you are still relying heavily on a 3rd party format and engine that's usually modified off another one. The need to convert more than once is ineffecient, I wanna snap my fingers and that thing is loaded and already rendering without too much need for 3rd party intervention.

In a simple game engine class I use:
1 line of code to create/load the mesh. (Loads mesh, materials/textures, etc.)
1 line of code to render it.

Myagi
07-31-2005, 07:30 AM
I do it all so I have very little time to spend on complications these days, I wanna focus on my development and productivity, my application, and I want it simple and straight forward with as little headaches as possible.

These are the exact reasons a lot of people do write their own tools and have their custom formats. If I have the choice of spending two or three hours on an exporter and get exactly what I need out from it, or using some existing format which almost contains what I need, but not quite, then I'd pick the former. Trying to fit an almost correct puzzle piece with a hammer just causes more anger and lots of cursing :)

In developement everyone has their own requirements and goals, which is why trying make it as easy as possible to adjust to those requirements (ie. easier to create/adjust the tools you need) would be good. The idea is that the easier it is to create/modify it yourself the less of a "complication", as you see it, it becomes.

Like I said, throw in some exporters for common formats out of the box, that's fine and all, but that's not going to help those users who need customization. We aren't quite at the point in computer graphics where one global format fits everyone's needs. And spending the time on customizing some X or MD3 importer instead (on the engine side) to fit my shoe is a lot less appealing than just having an exporter that gives me exactly what I need.

One example that could help both "fractions" for example, would be if they included a good exporter (for X or whatever) and the source code for it, so that you have easy access to an exporting framework but can quickly modify it to get what you need from it. (releasing more source is one part of making developement easier, along with improved SDK and features, and the whole subject is about more than just exporters).

Knight Chat X
07-31-2005, 08:53 AM
Bro, it's the DirectX format.

The documentation for making custom plugins is exactly what they use to make these custom formats to begin with, the reason these custom formats are normally made has nothing to do with adding or removing just extra features, because the main features the DirectX format provides is clear enough to understand.

It's just like back in the early VRML days and we've come along way since then.

I can understand someone wanting to add extra bits of info to a file which stores standard DX geometric and related data, or changing the .x extension from .x to .whatever just so it matches the name of their game engine, or adding encryption so the file is partially secure, I just don't get it, all the functionality is already there, the settings to save as text, binary, optimize, compress meshes, DirectX already provides all the standard modeling, loading, saving, and rendering functions to begin with, so I know NewTek could easily implement this functionality and probably has been able to for years, it's just a question of why they haven't taken the time to just do it, it's as simple as supporting built-in .BMP exporting come on... The problem with not already having this functionality built into lightwave is that it's lacking something that's used frequently by developers that use DirectX Direct3D and use Lightwave as a quick modeling/render tool to serve a purpose.

I don't want another format or immitation I want the real deal.

How it is with tools I think this, I use a hammer because it's strong enough to get the job done on jobs that require using a hammer, if the wood is too rotten to withstand being hit by the hammer and it breaks, I just replace the board with one that's strong enough to handle it. Because weak boards aren't a good idea, though some people tend to get lazy and say well I'll just paint over it to make it look nicer, the board is still bad and if it was a patio or deck you wouldn't want people to stand on a weak rotten one, with parts missing falling apart, it needs to be complete and stable, not half a##, and you need the proper parts and tools to fix or build a new one, if it's too difficult to repair and requires more than 90% repair I'd just bulldoze it and start over build a new one and make sure it lasts longer next time.

On the later you are right, they need to just add it, simple, the source code has been around for years, so JUST DO IT!

lol

Myagi
07-31-2005, 10:09 AM
Clearly you are an authority on the subject, all developers should never need to use any formats other than .x or other custom tools, thus improving custom developement in LW by NewTek is pointless, I'm glad that is settled.


Thank you and goodbye for this discussion.

Knight Chat X
07-31-2005, 04:11 PM
Clearly you are an authority on the subject, all developers should never need to use any formats other than .x or other custom tools, thus improving custom developement in LW by NewTek is pointless, I'm glad that is settled.

Thank you and goodbye for this discussion.

Somethin like that, nothing wrong with customization, I mean it's not gonna make it to where it can't be customized, the standard feature is just missing in Lightwave, the exporter plugin source code is available, and it'd save game developers alot of time and headaches of having to find and use 3rd party exporter/modeling tools/converters/and game engines, when it could all be made in lightwave as normal, exported from Lightwave in it's native DX format, then imported as-is into DX application, simple. Not only that, it'd save mucho dollars, so there are more ups then downs to it!

Adrian Lopez
08-03-2005, 01:39 AM
it could all be made in lightwave as normal, exported from Lightwave in it's native DX format, then imported as-is into DX application, simple.Lightwave is built on top of OpenGL, not on top of Direct3D. Furthermore, much of the information stored by Lightwave is intended to support its proprietary rendering engine and other features unrelated to realtime graphics. Therefore, you should not expect a one-to-one relationship between Lightwave's internal data representation and that required by realtime engines.

Lamont
08-03-2005, 01:47 AM
I don't follow what you're saying. Because you can take any data you want out of LW and represent it any way you want by a realtime engine.

Adrian Lopez
08-03-2005, 02:32 AM
I don't follow what you're saying. Because you can take any data you want out of LW and represent it any way you want by a realtime engine.The best example would be Lightwave's shaders. Because Lightwave does not use FX shader files internally, there is no way for a plugin to export Lightwave's shader effects without first having a human reimplement them in whatever shading language is used by the game engine. Similarly, there is currently no way to preview an FX shader within Lightwave, and no straightforward way to refer to refer to these external FX shaders from inside Lightwave. Of course, none of this is an argument against the inclusion of a Lightwave to DX exporter in the standard package. I guess what I'm really trying to say is that exporting a model into a game is not always as straightforward as File -> Export, and that a DX exporter would be of limited use to game developers with special engine requirements.

Knight Chat X
08-03-2005, 03:48 AM
OpenGL, that makes sense, OpenGL provides Linux support.

I always thought LightWave had some ties with gaming, hmmm.

You know somethin that's funny though, it's funny how someone can make a plugin which exports this very data you mention that isn't able too, of coarse shaders are a new concept, but the DirectX SDK has already supported this for awhile now, HLSL etc. I don't use shaders at this point, I know it's just like doing it the old way only you create a script/.fx file to define how you will process something to apply some custom effect, such as a texture, which is bout the same as applying multiple layers of textures to achieve various effects.

Using a tool such as NVidia's Composer, or ATI's RenderMonkey enables you to easily create and view this stuff, that is specific to shaders though, and if you load mesh with the shader anyways it'll already be referenced to in the DX File once saved.

DirectX has advanced quiet a bit now and most basic tasks are performed automatically without you needing to worry bout complex code, whatever information is inside that DirectX file as long as it follows the standard the information is automatically loaded from that file when you load the mesh, this includes material, texture, and now shader information, most features are called upon using enumerated option parameters within functions. Special operations such as simplify mesh are also that simple now.

If I save a DX file and the textures and shaders/.fx scripts are in: "C:\content"

That's where they'll be referenced inside the .x file once saved.

I think what the issue really is in this case is that the rendering happens in OpenGL and there is lack of knowledge on how to export it to DirectX's native format, if so, I'd definately contact the ones that made it work because they definately know how to do it because it just works, lol.

As for realtime rendering, whenever you work within a modeling program and are able to move about in a 3D environment in various viewports, well, you are rendering in realtime and are making changes in realtime to objects, for example, when you scale a box, you see the geometric changes in viewports, thus, it is in realtime, else you would only see changes when you click button to render a still frame. Of coarse when you use image viewer to render a still frame that of coarse is not realtime, but instead a generated snapshot which is processed. So in a way it would be hard to see how these things aren't hand in hand.

Adrian Lopez
08-03-2005, 05:26 AM
You know somethin that's funny though, it's funny how someone can make a plugin which exports this very data you mention that isn't able tooNo plugin is able to export arbitrary Lightwave shaders, in part because the plugin's author must know what the shaders do and then reimplement them as FX shaders, but also because plugins have no way to determine which shaders are assigned to which surfaces, as the current version of the Lightwave SDK does not provide that information (then again, Worley has convinced NewTek to add such a feature to a future version of the SDK).


of coarse shaders are a new concept, but the DirectX SDK has already supported this for awhile now, HLSL etcDirectX does, Lightwave doesn't.


I think what the issue really is in this case is that the rendering happens in OpenGL and there is lack of knowledge on how to export it to DirectX's native formatIt has nothing to do with OpenGL and everything to do with the fact that Lightwave is first and foremost a tool for prerendered graphics. I mentioned OpenGL because you spoke of Lightwave's "native DX format", as if to imply that no conversion was really necessary.


As for realtime rendering, whenever you work within a modeling program and are able to move about in a 3D environment in various viewports, well, you are rendering in realtime and are making changes in realtime to objects, for example, when you scale a box, you see the geometric changes in viewports, thus, it is in realtime, else you would only see changes when you click button to render a still frame.I never said that Lightwave can't be used to create meshes and animations for realtime graphics. In fact, I said that "none of this is an argument against the inclusion of a Lightwave to DX exporter in the standard package."

somnambulance
08-03-2005, 10:59 AM
shaders... you guys are arguing over shaders... How often are you guys using shaders in games?

Lamont
08-03-2005, 11:04 AM
shaders... you guys are arguing over shaders... How often are you guys using shaders in games?It's just "The Airing of Grievances".

http://www.cbrsd.org/nessacus/festivus/grievances_files/airing11.gif

Knight Chat X
08-03-2005, 11:05 AM
So an exporter is going to be implemented someday or no?

And if not, why not?

Lamont
08-03-2005, 11:15 AM
It's just up to someone to do it. Maybe someone is working on it, maybe not. It would be really nice, because I have to use a tool that is not intuitive right now.

If the next version of LW allows for programmer to do so, I can see it within a year. But better to be sooner than later with NextGen systems using nVidia and ATI. H3ll, even film and print can take something from using them.

BUT, you can always tag surfaces in LW with params and have whatever export you write look for those flags and apply a shader that was created in an external tool hook on to it. I prefer to make everything in one app though.

Adrian Lopez
08-03-2005, 04:50 PM
shaders... you guys are arguing over shaders... How often are you guys using shaders in games?All modern game engines are built around the concept of pixel and vertex shaders, so any artist who develops for a modern game engine requires some kind of shader support. On the other hand, I don't think there's any reason for a DX export plugin to support Lightwave's native shaders, as it's always possible to create a plugin that pops up a preview window. I only bring it up as an example of the lack of a one-to-one relationship between Lightwave's format and game engine formats.

To be honest, I am mostly nitpicking, and there's nothing wrong with Newtek creating an export plugin for Microsoft's X format. Then again, how many commercial engines use X as their native format?

Vincenzo
08-05-2005, 09:45 PM
Ok. I am currently writing a LW importer. I have to parse all the chunks and use the ones I want and skipp the chunks I dont need. Then I have to match up the various properties that are in the chunks with different shaders. For example, suppose an object only has a color texture. I could represent this object with a vertex format, or decl, that includes a single set of texture coords, a position, and normal coordinates. Now consider another object that has both a color and bump map texture. I could actually use the same vertex format for the VBuffer, but my V. Shader and P.shaders would have to be different. When one considers that LWO s can have an infinite number of possible color layer textures, the same goes for Bump maps, Spec maps, etc, one realizes one cannot represent all the features of all possible LW objects with Vextex and Pixel shaders. One has to limit the features of the LW objects that they will bring in to the shaders that they will be using. The problem is that everyone wants to use their own custom shaders. This makes it hard for Newtek to provide a generic importer.

Vincenzo

TripD
08-05-2005, 10:33 PM
Hmmm,

This discussion has my mind spinning......again. It seems to me that since Newtek already has the expertise in render software, why the heck don't they come up with their own generic game engine. Create an OpenGL open architecture engine that leverages the Lightwave formats. Cheap licensing for Lighwave users (of course).

clink clink

Sande
08-08-2005, 10:48 PM
Hmmm,

This discussion has my mind spinning......again. It seems to me that since Newtek already has the expertise in render software, why the heck don't they come up with their own generic game engine. Create an OpenGL open architecture engine that leverages the Lightwave formats. Cheap licensing for Lighwave users (of course).

clink clink

Have you checked your Lightwave's OpenGL-performance lately? :help:
Or did you already got yourself Lightwave 9? ;)

Seriously, I'm pretty sure Newtek has more than enough job to do keeping it's 3D-software competitive... Creating game engines and creating 3D-software are two very different things and I'd like to see Newtek do one job decently than two jobs poorly.