Brent Taylor
-
Posts
215 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Brent Taylor
-
-
You start by having a near finished title.
I'm not trying to be sarcastic, but if it's not anywhere near finished, they don't want anything to do with you.Get a near finished title and then look into steamworks. Beyond that, it's all behind an NDA.
-
Brent, perhaps you mean .FBX is Autodesk's format?
Unless things changed and I missed it (not being sarcastic, quite possible),
Collada was a direct counter-option to AD's .fbx.
http://en.wikipedia.org/wiki/COLLADA
(as a side-note, I've been using Silo since, uh...2005-06? for 95% of game models
you'd be hard-pressed to 'need' anything more...but everyone's different, of course)
I stand corrected. I did indeed get the ownership mixed up between the formats.
That said, nothing else seems to be able to open up Blender's exported collada files properly, be it autodesks software, Lightwave or even several other game engines.
As far as Silo, I happen to really like the software. There are some things that are a little cumbersome to me however. I'll end up grabbing a copy of Modo.
-
I don't think the dae from Blender 2.5 is wrong, but probably Unity and Torque import them wrongly. With Shiva and UU3D it worked perfectly. I don't use animations though, because I want to use physics for realtime IK and animations.
I'm going to have to disagree. Keep in mind, you're not using ANY of the features that are bugged. Don't use those features and they export just fine. Also, keep in mind that collada (DAE) is Autodesks format. I think it's safe to assume that their importers and exporters would work properly. Blender's DAE is bugged to hell.
-
In Blender 2.5 the dae export works very well. I tried it also with a 3D engine which uses dae as the main import format, and it created the model, mesh, materials and textures automatically correct. I think a fully featured dae importer should be done for LE also, so that the pipeline from Blender 2.5 to LE is just a single click export and import.
*chuckle* Oddly enough, you picked the exporter with the most bugs. It doesn't maintain proper hierarchies for bones when dealing with FK/IK constraints. It doesn't order verts properly, nor faces (this is evident when exporting the default cylinder and importing it into Torque, any of Autodesk's software or Lightwave). It doesn't maintain smoothing groups (in fact it doesn't export them at all). Just a lot of little things that turn into showstopping bugs on larger projects.
FBX on the other hand, I've only run into two issues. First of all it doesn't always export all texture layers (or texture slots). It will consistently export the first, but anything past that is hit or miss. I've no idea why. The second issue may not be a Blender issue and may be a UDK issue (which for me at this point, doesn't matter).
Currently I'm using the FBX exporter, importing into Milkshape 3D and re-exporting to whatever format I need. I fix the texture layer issue in Milkshape when needed as well. It works, but it's not optimal.
----
The one thing about Blender that bugs me is how IK is setup. For it to work properly (unless you're using Auto-IK, which is limiting) is to have a separate, non parented bone (that also doesn't influence ANYTHING) control the IK. In just about any other package IK works much like Blender's "auto-IK", just without the limitations. If really necessary, nulls or Empties can be used as controllers (and this is common. Rigging can get very complex very quickly).
The reason this is an issue is when exported to a game engine, that extra bone is also automatically exported and has to be processed at runtime for every frame. That's just a horrible way to handle it, especially seeing as it's a solved problem elsewhere.
</rant>
-
I don't personally have any problems with Blender, although I first disliked the 2.5 GUI, but now I got used to it too, and it fits also better with other modern GUI software. Of course I'm not an artist, but still I can do quite nice things with Blender, like 3D terrain sculpting and some simple models. Since my ideology is anyway functionality before visuality, I am very happy that I can make small and modular models with Blender.
I actually like Blender and quite a bit. The problem is the exporters seem to be perpetually bugged.
@Naughty Alien
I'm sure it will change over time. Everything does.
What worries me most is the ever present threat of Autodesk acquiring them. I'd rather go into the unknown than face certain disaster elsewhere. -
Here's a little background first.
Three years ago I bought a full license for SoftImage 6.02/6.05. I didn't buy a trial. Nor am I "renting" the software. I've checked the original user agreement and TOS I digitally "signed" upon installation and upon purchase. I bought a permanent license. I've been using it happily ever since. However, recently I received an e-mail from Autodesk informing me that after August 1st of this year, I would no longer be able to activate the software unless I upgraded to the latest version (which is $3k USD). For those that don't know, you can't use SoftImage without an activated copy. So, either pay up $3k, or be unable to install SoftImage after August 1st. Does this sound like blackmail to anyone else? I'm unsure if this is even legal (keep in mind I bought the software before Autodesk bought out SoftImage). Legal or not, I certainly do not have the cash to fight this.
So, I found myself with the need to upgrade or buy some new 3D modeling software. I tried Blender, Cinema 4D and Houdini and dismissed each for one reason or another.
This left me with Lightwave 3D. Downloaded the trial, loaded the documentation and even subscribed to Lynda.com to go through their tutorials on the software. All in all, I'm pretty impressed. Cheaper than the competition and rather capable. I love the separation of Modeling tools and Scene management (Modeler and Layout, respectively). It has fairly nice animation capabilities and integrates fantastically with Messiah Studio. My only issue with it are the modeling tools. All the functionality is there, it's just a little old school. I can deal with that, or I can augment it with software like Silo or Modo. Lightwave 3D made the cut.
Because of the modeling tools in Lightwave, and because Silo 3D looks to be stagnating in terms of development, I decided to try out the Modo evaluation. I figure, even combined with a Lightwave license I'm still under $2k which is a heck of a lot cheaper than SoftImage. So I try the evaluation. I found the documentation a little sparse as it seemed mostly geared to beginners to modeling (things like "this is a polygon", etc), but despite that I picked it up fairly quickly. The interface itself is a little quirky, but the tools are intuitive and most importantly the tools are FAST to work with. So I settle on the combination of Lightwave and Modo.
I don't have the cash for this at the moment, but saving has always been one of my strengths. A little time passes and this morning I get a call from Luxology (the makers of Modo). Now I'd like to point out, I'm not a customer. Just someone who tried out the evaluation. I get a call from, what I believe is one of their customer service representatives, wanting to know how I found the evaluation and if there was anything they could do to help me learn the software. Most importantly he was very insistent on what he could do to help and what would make my experience better. This says so much about Luxology as a company. They clearly care about their customers.
A few hours later I get an e-mail from him with a ton of links to documentation, tutorial video's and PDF documentation that looks to only come with the full version of the software. In addition he re-activated my trial and updated it to the latest version. I had already told him I was going to purchase a copy of Modo and the fact that he called to follow up on my experience cemented that decision. This is customer service and I'm not even a customer yet!
The differences between Autodesk and Luxology are just amazing to me.
-
1
-
-
But, I think what most programmers don't understand is that they shouldn't be so cocky to think that they're "God Of Programming" and that there is ever a little chance that someone else has a cool idea to improve your own work.
Like frednaar, I find Mono much better than every custom script editor you could build yourself for LE, because it supports very many different language, it's cross-platform and YES even scripting languages like Javascript or LUA can be coded there, please read here before judging. You could use Mono for LE to have one only IDE to program in LUA, C# and even C++ (this one only for Windows platform it seems).
You guys should do at least a little search before being so sure of what you think, or at least argue your thoughts.
Just thought that I'd point out that Mono is NOT an IDE nor an editor. It's a combination of a compiler (with multiple frontends to handle C#, IronPython, Boo, etc.) and a runtime. What you're thinking of is Mono Develop, which isn't related to the Mono project (it gets it's name because it runs on top of Mono and can be used as a frontend to the Mono toolchain, but they are completely separate projects and development teams).
I like the idea of embedding mono, but it's not something I'd push for from Josh either. If you want to embed Mono into Leadwerks, you've already got the tools to do so.
-
I think he's saying some of the controls are custom because out of the box MS doesn't have them in their default GUI. The common things like a button and the like would be using the default Windows button. There wouldn't be much point in making your own button since MS has one already for you, BUT if you wanted a button to do something MS's buttons doesn't that's where they are making their own.
That pretty much covers it, yes. Precisely like the Treeview control that Josh has created for LE3's editor. It's a custom widget.
Keep in mind Josh, QT and most other GUI toolkits don't use GDI or native widgets. They have their own rendering routines. They don't have access to ANY of the standard controls in any OS (with the exception of Nokia's OS's, where QT _IS_ the native GUI toolkit).
The base wxWidgets toolkit only provides widgets native to the OS (with a few exceptions*) and does use GDI's native controls (proof). Most applications written with wxWidgets just use the standard widgets, or modify their functionality. Much like how you're building the LE3 Editor. You could create custom widgets for everything to give visual flare if you wanted. But you're sane and don't do so. You create custom widgets only when you need functionality that isn't provided.
It's precisely the way MaxGUI works actually. Under windows it's a wrapper around GDI as well (proof). When the native toolkit doesn't provide functionality you need, you create a custom widget. It's not terribly complicated concept. The creators of Code Blocks and Audacity however, for whatever reason, decided to create completely custom drawn widgets for a lot of their application. Do I agree with their decision? Heck no. Is it a problem with the GUI library used? Not in the slightest.
When you write an application in wxWidgets, it will look different on every OS purely because it will use the native windowing API's for the system. GDI on Windows, GTK under linux (which doesn't HAVE a native GUI library) and I believe it's using Cocoa under OS X.
*Exceptions being like MDI under OS X and Linux. MDI is a windows paradigm, and while the controls are "supported" under other OS's, they're converted by the runtime to native tabbed interfaces and the like. There are only a couple of controls that do things like that, and they are well documented.
----
As I said though, use what makes you the most productive. The only reason I would bother switching to something other than Blitz for writing the editor would be my concern of Blitz applications no longer working on future versions of OS X. I expect Blitz and MaxGUI will continue to work on Windows and Linux for quite some time.
----
If it's using GDI to draw custom widgets, then how can that be considered the standard GUI? By that definition anything is the standard GUI, as long as it's drawn on a Windows window with GDI.
That's not what I said. I was pointing out that those two applications are using custom widgets. wxWidgets by itself does not. In precisely the same way that MaxGUI provides native widgets. Both however give you the option of creating custom widgets, if those provided by the system to not offer the functionality needed by your application.
-
It's similar to Windows, but you're blind if you think this is the standard Windows GUI:
Code::Blocks gas a lot of redraw bugs when the panels are resized. You'll get a big chunk of the window grayed out because it didn't redraw right.
On top of that, wxWidgets has the absolute worst command design possible. Every single widget you create is its own class! It's ridiculous.
*sigh* I'm not blind and I've worked with the code base. However, you're confusing custom drawn widgets with native controls. Code Blocks is using a lot of custom widgets as do most applications. As you're very much aware (having created them yourself for the LE3 editor) most GUI toolkits allow for custom widgets. wxWidgets (and GDI under windows, as that is what is being used internally) of course also allows this functionality.
It's really pointless to argue this. wxWidgets is under the MIT license, feel free to check out the source. I have.
----
You don't have to like wxWidgets. I honestly don't care what you use, as long as you're productive in it. That said, don't spread FUD either.
-
BTW can you believe MFC. I have a hard time believing MS tried to pass that off as anything but a POS.
MFC is a perfect example of the engineering at Microsoft back in the day. Overall, the concepts and paradigms in MFC are very well engineered. They then took those concepts and paradigms and took them entirely too far. And then created an even worse implementation.
It's one of the reason I like wxWidgets. It uses the same concepts and paradigms, but scales them back to an appropriate level and keeps a nice, clean and usable implementation.
-
That's a complete lie. If wxWidgets used the native GUI, wxWidgets applications would be unrecognizable as being such. wxWidgets applications are easily recognizable and full of bugs.
This is why I say it's like talking to a wall whenever I bring this up. I just mention it, and everyone has to post a wall of text defending their favorite language.
Err...Josh, I've done *dev work on wxWidgets. It's using the native GUI lib on the system. As far as being "full of bugs", I'd like to see a source for that. No software is bug free mind you, but don't confuse bugs with the toolkit, and bugs in an individual program. High Priority wxWidget bug list.
I've no idea where you get the idea that wxWidgets applications are "instantly recognizable". As mentioned, it uses the native windowing kit of the system.
*By dev work, I mean I've poked around in the source and have made a couple of changes. Nothing official. But it is definitely using the native windowing kit on the system.
-
If you are talking about either MFC or C++ CLR then both of those are a complete joke. MFC is just ugly and macro driven when it doesn't need to be and C++ CLR is a frankenstein of a beast. Weren't they even discontinuing that soon anyway? It's not even "real" C++.
I'm talking about MFC. Yes, I don't like MFC either. There is also QT Creator (for QT) and wxGlade (for wxWidgets). They certainly make the job easier, even more so with QT (wxWidgets still being my favorite however. I hate qmake). It's still nowhere as easy as .NET with Winforms or WPF. Or Python with wxWidgets (and it's an almost identical library) or just about any managed language with a GUI library. The framework/standard library that ships with a language and the fundamental paradigms used in any language make a huge impact on ease and speed of development. Currently, C++ has the short end of the stick in that regard.
Show me the major differences in language and not framework that C++ can't do/simulate. Things like reflection is not the language itself but the framework. C++ has void* to simulate dynamic, I can simulate properties in C++ just like in C#, etc etc. At the core the biggest differences are at the framework level.
There is a significant difference between "provided out of the box" and "you can do that, but you have to make it". Reflection, properties, garbage collection and just about everything else are all possible to set up in C++. In general they are not trivial to create (some are however, easier than others). Are you seriously suggesting that you'd have shorter or easier development given that this is true? Yes, you could make a library for C++ that makes GUI development easy. That's theoretical. The library does not currently exist, and that is what matters. When you've created such a library, by all means lets revisit this.
That's what libraries are for. They are meant to hide the complexity and give the user (the programmer in this case) a nice clean and easy to use interface. This is the problem with most C++ library writers especially in the open source world.
I'll do my demo and see what I can come up with. I'll compare it to a C# example of the same nature and see what the difference truly is. Note the C# glue code that the editor creates will be include as well since that's what you'd have to do without an IDE. Most people would had C# just as much for GUI programming as C++ without VS because it does so so much for the programmer.
Unless you intend to create a framework that rivals the .NET, Python, Ruby or <managed language of choice> standard libs/frameworks, it's still not going to be as easy or bug free. Again, the standard library and paradigms used in a language greatly effect ease of use and development time. In addition, you're talking about a theoretic GUI library, a library I might add, that is designed for a specific task. Just the GUI.
----
Don't get me wrong, I'm not saying don't use C++. It's a perfectly viable tool for any number of tasks. GUI dev just normally is not one of them as there are far better options.
-
Only because nobody has created a good API and IDE for that purpose. If someone would basically duplicate .NET but in C++ and the IDE would be the same then it would be no different. For GUI apps the IDE plays a massive role in how successful the API is. .NET wouldn't be as popular for GUI apps if it didn't have the IDE doing the heavy lifting for us. I mean why would it since something like C# is so close to C++. You can't tell me the small differences between the 2 languages (not frameworks, but languages) makes all the difference.
I'm going to have to get into Win 32 API programming again and make a C++ wrapper and IDE or something for people to see that the language has little to do with how "easy" writing a GUI app is. It's more about the framework and how it's setup.
You seem to be unaware that Visual Studio comes with an identical form designer for C++ as the .NET languages. It's not free as it's only in one of the paid VS packages. It works just as well as the C# and other .NET form designers. Coding for it however is still a very painful experience. C++, when used properly, is still a monstrous beast. If you honestly think the differences between C++ and C# are inconsequential, I'm afraid I'm left to believe you've never really used C++ for anything beyond the basics.
It's not that writing GUI's in C++ is difficult exactly. It's the fact that most things in C++, when done properly tend to be far more complicated than their .NET (or language of choice) implementations. In the end designing a GUI application (which in general does NOT have to be fast) in C++ is going to result in more dev time, more bugs and more code. Where's the advantage?
-
Josh, if you want a native GUI, you're pretty much stuck with wxWidgets if you want it cross platform. That said, using C++ for GUI development of any kind is a pain in the rear. Might I suggest Python with wxPython (a nice wxWidgets lib for Python)? You can create native style executables with py2exe, py2app and freeze under Linux. Just about all of my cross platform GUI apps have been developed this way and it's trivial to do.
*Just to be clear, I'm not suggesting you write the editor NOW. Just in the future if you do decide to write the editor in another language due to blitz no longer being supported.
-
PhysX 3.0 is out: http://www.guru3d.com/news/nvidia-physx-30-announced
But it seems PhysX is still not supporting OpenCL, which makes it basically slower on all cards (nvidia+ati average value) than Bullet, because Bullet supports OpenCL.
More specifically Bullet WILL support OpenCL. As pointed out in your quote, the OpenCL standard isn't public yet. I expect most physics engines will move over to it once it's been standardized. PhysX is still a good move.
-
Good luck with that.
I'm not trying to cause trouble, but while the Collada format is nice...no one implements the exporters properly, and I mean NO ONE. Maya, Blender, SoftImage and 3DS Max all have their quirks in their importers and exporters (in Blenders case they are severe). Part of the problem is everyone has their own implementation. -
-
I always thought the poly count for exported poser models was far to high for game use as they stand. Maybe that's changed recently I don't know.
I'm not sure if thats true or not (I've never used Poser), however if it is, there are apps like Decimator and such that can greatly lower polycount very quickly. They don't necessarily do an optimal job, but they don't require any skill to use either.
-
To each their own for sure.
-
I'm not trying to be rude, but at some point you're going to need some experience with a real modelling application to get anything done, in any engine. What you want to do is fairly trivial in a traditional modelling App such as Maya or (on the free end) Blender. You can bake your BVH animations and export your model as an FBX file. From there you can convert it directly with fbxtogmf, or use UU3D. But you are going to have to learn a modelling app, at least some of it anyway.
-
I think yes and no. Not sure if you were around when Pancakes was here but he was not a coder at all and he created a pretty complex battle system using a flowgraph from Blender I believe it was. UDK's Kismet is an example of this as well.
In what I'm playing with I'm taking it a step farther and picturing a world where you are programming almost line for line in flowgraphs the same as in C++. How you make your flowgraphs shouldn't be much different in how you code. Make small pieces of flowgraphs that you fit together. I can make an unmanageable flowgraph just like I can make an unmanageable function. I believe flowgraphs can be just as easy if not easier (since most people are visual learners) than coding in a typed language.
I know many various languages and I switch between about 3-4 on a daily basis between work and hobby. The idea of thinking logically doesn't change between them but the syntax does. Should the syntax really matter or should the logical thinking matter? Clearly logical thinking is the entire point of making a computer do something. So I asked myself how would we remove the syntax aspect then since it's not required. Syntax isn't the only reason of course but it's a reason. I also believe that reading code would be faster because of the visual aspect. Given certain colors and shapes being used to represent things, at a fast glance you could tell what is sort of going on.
These are my hopes anyway.
Don't forget, I actually do have experience with Blender, and especially the UDK.
Node graphs are great and all for a lot of things. Game logic just isn't one of them IMHO. It gets to be quite the mess if you use strictly kismet for everything in the UDK, rather than just code things out.It's not the syntax difference thats the issue, but the visual feedback gets overly confusing. It's an issue of visual overload. I know you're working on a tool to do just this, and I wish you the best of luck.
To get an idea of exactly what you're creating, I highly suggest you look into Alice. http://www.alice.org/ It's not a node graph implementation, per say, but it's not far off. It uses drag and drop for line by line code generation. Try picturing doing something even remotely close to this using SoftImage ICE nodes or via Blender's node system. You're going to find it gets very complex very quickly.
-
was hoping for something like Softimage's ICE:
(early implementation, disregard audio)Have a look around youtube for additional vids on Softimage ICE...there's fluid sim nodes, particle sim nodes, etc.
Is there a reason LE 'nodes' couldn't be self-contained complex logic? I would think there could be some compelling reasons
to allow the system to accept higher-level functionality...namely, a more desirable means for merchants (programmers) to create
and profit from their effort. Maybe somebody has a Tessendorf wave 'node' they'd like to create and sell so folks like Red October
(or anyone dealing with an ocean-based game) could have that option to purchase and 'plug-in' to their ocean geometry...
Frankly, being able to have a standardized means of offering these node plug-ins would seem to be a huge boost in enhancing the
ability for games to be made with LE. (Animation-blending/Managing node, Substance texture integration node, ocean nodes, sky nodes,
ragdoll node, particle node, car-physics node, cut-scene/camera node .... etc, etc.)
I'm a huge fan of ICE, but for what you're talking about it wouldn't be optimal. As soon as you start getting into any sort of reasonably complex game mechanics (and most games have more than a single mechanic) the node graphs start to get unwieldy. The only reason they work so well for shader creation, is you can usually get up to the node visual feedback of what's going on up and down the node chain. That just doesn't work very well in practice when dealing with code and that can be seen in SoftImage's ICE as well. It's great for non programmers, but it gets hard to follow very very quickly for everyone involved.
-
You can't write an engine in C#. It would be horribly slow.
If the end user could only use C# for XNA programming, that would be okayish, but there's no way I can rewrite the whole engine just for one platform. I doubt they would allow Lua either, and that it is pretty bad.
Oh you can certainly write an engine in C#. But as mentioned, it does take a decent amount of knowledge to get it running at acceptable speeds. Admittedly, the same can be said about an engine written in C++. A crappy programmer is going to produce crappy code, not matter the language used.
As for Lua, actually you're going to find Lua can be used for XNA dev. There's a .NET port of Lua that works just fine on the compact runtime.
But whether you should even consider porting to XNA is a pretty easy question. Are you looking to target Indies for console dev, or professionals? Unfortunately "both" isn't much of an option here, considering dev kit requirements. In addition, if you were to port to XNA, is there enough interest to warrant the time spent rewriting the engine from scratch?
-
I'm not trying to be sarcastic, but if it's not anywhere near finished, they don't want anything to do with you.
What worries me most is the ever present threat of Autodesk acquiring them. I'd rather go into the unknown than face certain disaster elsewhere.
Steam and Leadwerks
in General Discussion
Posted
Well no, keep in mind, steamworks doesn't do a whole lot. The steam overlay and all that stuff works automatically on ANY game run via steam (remember, you can launch non steam games via steam). Steamworks is primarily just achievements and VoIP. Both of which are trivial to add to a code base. Giving that out to everyone would be ridiculous, considering that functionality uses and runs ON steams servers.
Remember, getting published on steam isn't just an added API. That's the easy part. Valve actually does marketing and such for your game, as well as helping you polish your game and such. It's a big investment on their part. If they are going to provide support via an API that integrates into steam as well as marketing and experience...It makes a heck of a lot of sense to want a near finished product to work with. It shows you actually have something you might finish. Otherwise they're going to get a huge influx of half finished games with authors that lose interest. That costs Valve money.