[osg-users] Epic releases free version of Unreal Editor
Jean-Sébastien Guay
I expect most of you have already seen this:
http://www.develop-online.net/news/33198/Epic-releases-free-version-of-Unreal-Engine
I'm mostly interested in this for the toolset, which is apparently very
robust. If the file formats are reasonably open and we can make plugins
to read the data that comes out, it may be an excellent way to create
very good assets for OSG-based projects.
Consider the following scenario: someone has been doing game assets for
a while now and feels very comfortable in that kind of pipeline. Now,
they want to start having a family, or maybe just have a more stable
work schedule without all the crunch times that game development
companies still impose. Well, companies making simulators, serious
games, or other 3D products might be able to hire these people more
easily if they can adopt toolsets that those people are familiar with.
I think that kind of scenario will become more common as the huge teams
of game artists start aging, which is already starting and will only
increase in the next few years. Kind of analogous to the general
population with all the baby-boomers these days.
And on a completely selfish note, I know our own content creation
pipeline could use some help... Especially once we start integrating
more effects, it's going to get hairy. So I'll be checking this out for
sure to see if it can help.
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-seba...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Simon Hammett
with the release before UT 2K3
It was crap then and I doubt it's got any better. The last UT sucked
nads. And actually so did the one
before that.
It was pretty much on a par with Valve's 'Hammer Editor' which is also
a massive ball suck,
but hey at least Valve are a success so you might be able to find some
talented level designers
who know how to use it.
And AFAIK they both share roots with the early ID toolset from Doom/Quake days.
At least ID had the excuse of being Pioneers.
Call me cynical but I don't see this as any more than a last gasp of
an irrelevant game dev. studio.
I'm still waiting for DN'em Forever.... ;)
2009/11/6 Jean-Sébastien Guay <jean-seba...@cm-labs.com>:
Jean-Sébastien Guay
> Yeah I spent quite a bit of time playing with the UT editor way back
> with the release before UT 2K3
> It was crap then and I doubt it's got any better.
This release is not the level editor that shipped with any of the games.
It's the toolset that was used to create the assets for the games (along
with the engine itself). It was not previously available without paying
a lot of money for licenses of the SDK.
> Call me cynical but I don't see this as any more than a last gasp of
> an irrelevant game dev. studio.
The problem with that reasoning is that the Unreal Engine is not used
only by Epic in their own games (even though "the last UT sucked nads"
which is a very compelling and objective argument) but by a very large
number of other devs. That was the basis of my argument about large
numbers of people knowing the toolset.
Once again, we're not talking about the freely downloadable level
editor, but the actual toolset and engine used by the game development
teams to create assets, scripts, etc. during development of the games.
From what I've heard, the Unreal Engine is one of the most
well-regarded toolsets in the industry. Many many games have been made
with it, in many genres, including shooters, RPGs, MMOs, etc. Look it up.
Jeremy Moles
> Hi Simon,
>
> > Yeah I spent quite a bit of time playing with the UT editor way back
> > with the release before UT 2K3
> > It was crap then and I doubt it's got any better.
>
> This release is not the level editor that shipped with any of the games.
> It's the toolset that was used to create the assets for the games (along
> with the engine itself). It was not previously available without paying
> a lot of money for licenses of the SDK.
>
> > Call me cynical but I don't see this as any more than a last gasp of
> > an irrelevant game dev. studio.
>
> The problem with that reasoning is that the Unreal Engine is not used
> only by Epic in their own games (even though "the last UT sucked nads"
> which is a very compelling and objective argument) but by a very large
> number of other devs. That was the basis of my argument about large
> numbers of people knowing the toolset.
>
> Once again, we're not talking about the freely downloadable level
> editor, but the actual toolset and engine used by the game development
> teams to create assets, scripts, etc. during development of the games.
> From what I've heard, the Unreal Engine is one of the most
> well-regarded toolsets in the industry. Many many games have been made
> with it, in many genres, including shooters, RPGs, MMOs, etc. Look it up.
I read the commercial licensing and I refused to learn anything more.
25% of your revenue? No thanks.
> J-S
--
Follow us on Twitter! http://twitter.com/emperorlinux
EmperorLinux, Inc.
http://www.emperorlinux.com
1-888-651-6686
hann...@gmx.at
> Licensing Options and Prices
>
> All the prices are per-project (however, licenses for unlimited
> titles are also available) and royalty-free! Prices are in US
> dollars.
>
> License Type Price Technical Support Updates Access Full Source
> Code Binary Indie* $4990 + $19900 1 month 2 years - Source Indie*
> $9980 + $29900 2 months 2 years yes Binary $25000 6 months
> lifetime - Source $40000 12 months lifetime yes Non-Game
> Application to be discussed
>
> *: "Indie" licenses are available for small independent studios only.
> The first part of the price is an initial payment, the second one is
> to be paid after getting funding from any kind of investor or before
> official release of the Unigine-based product.
>
> Technical support is provided directly by Unigine developers via
> e-mail, phone and IM services.
>
> Updates are provided no matter what version number of Unigine will be
> released. Thus there will be no need in any additional payments to
> upgrade to further versions during this period.
>
> Please note that we are open to any reasonable proposals also.
> Evaluation Kit
>
> Our free Evaluation Kit includes everything you'll find in Unigine
> except the source code and C++ API access. It contains the tools and
> plugins (except for Archiver utility), full documentation, samples
> and demos you'll need to determine whether Unigine is right for your
> project or not.
>
> Request the Evaluation Kit for free by e-mail: sa...@unigine.com.
> Ordering Procedure
>
> 1. Contact us by means of e-mail: sa...@unigine.com. 2. Enter into a
> license agreement, exchange signed copies. 3. Pay via bank transfer
> to our corporate account. 4. Get Unigine SDK access and registration
> in our updates system.
looks much better
Jean-Sébastien Guay
> looks much better
I didn't mean to start a discussion about engine licensing and use. I
assumed that if we're here it's probably because we want to use OSG and
design / write our own engines!
I was focusing on the toolset. And in fact, I was probably overly
enthusiastic about the Unreal toolset being available, because the
licensing terms say that it (the engine in this case includes the
toolset) can only be used for free for noncommercial and educational
projects. So that rules out using it to make assets for an OSG-based
commercial project, which is what I was excited about.
Oh well. I guess Blender + text editor is still the (free) toolset of
choice...
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-seba...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
Jeremy Moles
> Hi all,
>
> > looks much better
>
> I didn't mean to start a discussion about engine licensing and use. I
> assumed that if we're here it's probably because we want to use OSG and
> design / write our own engines!
>
> I was focusing on the toolset. And in fact, I was probably overly
> enthusiastic about the Unreal toolset being available, because the
> licensing terms say that it (the engine in this case includes the
> toolset) can only be used for free for noncommercial and educational
> projects. So that rules out using it to make assets for an OSG-based
> commercial project, which is what I was excited about.
>
> Oh well. I guess Blender + text editor is still the (free) toolset of
> choice...
You bring up an interesting point. What do you think is missing in the
OSG world in terms of external tools? There used to be something called
osgedit, but I recall it being extremely annoying to build. And I also
remember a world editor called "GROME" purporting to include OSG, but I
never investigated it.
I'd be interested in what you had to say about it, since you have a good
understanding of this kind of thing. :)
> J-S
--
Follow us on Twitter! http://twitter.com/emperorlinux
EmperorLinux, Inc.
http://www.emperorlinux.com
1-888-651-6686
_______________________________________________
Simon Hammett
> Hi all,
>
>> looks much better
>
> I didn't mean to start a discussion about engine licensing and use. I
> assumed that if we're here it's probably because we want to use OSG and
> design / write our own engines!
>
> I was focusing on the toolset. And in fact, I was probably overly
> enthusiastic about the Unreal toolset being available, because the licensing
> terms say that it (the engine in this case includes the toolset) can only be
> used for free for noncommercial and educational projects. So that rules out
> using it to make assets for an OSG-based commercial project, which is what I
> was excited about.
>
> Oh well. I guess Blender + text editor is still the (free) toolset of
> choice...
Yah, blender is the only tool I've found useful with osg so far.
Even then you have to be careful.
I've gotten good results with exporting blender -> .lwo as long as you
split your model meshes up the right way, so you can run the smoothing visitor
on it.
At some point when I've got time I would like to add crease angle support
to the visitor which would make modelling a whole lot easier.
It would be nice if osg could load directly out of .blend files, but the code in
blender that deals with the file format is huge.
Maybe somebody who is particularly bored could have a go at
refactoring the .blend
code into a separate library.
Jean-Sébastien Guay
> You bring up an interesting point. What do you think is missing in the
> OSG world in terms of external tools? There used to be something called
> osgedit, but I recall it being extremely annoying to build. And I also
> remember a world editor called "GROME" purporting to include OSG, but I
> never investigated it.
Yeah, I've seen those, and I agree, they either didn't stay up to date
to new OSG versions or were a pain to compile.
> I'd be interested in what you had to say about it, since you have a good
> understanding of this kind of thing. :)
Well, I just think that asset creation is something that should be
facilitated. Of course, it's hard to make an all-in-one tool for OSG
since OSG itself is not an engine, and various engines will be made with
it supporting different things... But nevertheless, I've always found
getting assets into an OSG-based app, and looking the way you want them
to look, involved too many steps, too many tools and too much trial and
error.
Plugins that you install into modeling software are useful, but in
general they'll support a small subset of functionality and export that
into .osg or some other format. Also, they often try to shoe-horn some
of the modeling software's concepts into unrelated concepts of the OSG
format, which I find unintuitive. Plus they only cover part of the
pipeline. It would be nice to have an application that you could use for
the whole content creation pipeline, from modeling, texturing, applying
materials, shaders, and animation, and perhaps even event scripting.
(Disclaimer, I haven't tried using Cedric's most recent version of the
Blender plugin, it's probably light years ahead of the one I used in the
past and maybe it does most of the above. I promise I'll take a look at
it in the near future :-) )
I'm not looking to make OSG become Unity engine (look it up, the engine
*is* the toolset and it's pretty darn intuitive) but I just think the
pipeline could use some dedicated tools.
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-seba...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
Jeremy Moles
It is indeed, and he's one beast of a coder. :) I'm lucky I'm befriended
him long ago because he's almost always the first person I ask for OSG
help...
> I'm not looking to make OSG become Unity engine (look it up, the engine
> *is* the toolset and it's pretty darn intuitive) but I just think the
> pipeline could use some dedicated tools.
>
> J-S
--
Follow us on Twitter! http://twitter.com/emperorlinux
EmperorLinux, Inc.
http://www.emperorlinux.com
1-888-651-6686
_______________________________________________
Jan Ciger
> I've gotten good results with exporting blender -> .lwo as long as you
> split your model meshes up the right way, so you can run the smoothing
> visitor on it.
Why? There is osg exporter too. Works fine:
http://projects.blender.org/projects/osgexport/
> It would be nice if osg could load directly out of .blend files, but the
> code in blender that deals with the file format is huge.
>
> Maybe somebody who is particularly bored could have a go at
> refactoring the .blend
> code into a separate library.
Again, this exists already, even though you probably do not want to do it. The
.blend files are more containers of a lot of different things than a scenegraph-
like structure and the mapping will be tricky. The library is called
"readblend" and comes with the Bullet physics engine.
Jan
Simon Hammett
> Simon Hammett <s.d.h...@googlemail.com> wrote:
>> I've gotten good results with exporting blender -> .lwo as long as you
>> split your model meshes up the right way, so you can run the smoothing
>> visitor on it.
>
> Why? There is osg exporter too. Works fine:
> http://projects.blender.org/projects/osgexport/
Well .lwo was the first format I found that worked and it's binary so
the models load quickly.
The apps I work on, load lots of stuff outta dbs, run third party dlls
& black boxes etc
on start up, so they are already irritatingly slow to start up.
There's also the problem with setting up new machines to run a project;
It takes ages to join the code co-op projects, install boost & other libraries,
black boxes, etc, etc. Adding another step of installing blender and
then getting
the export script as well just makes things take longer.
>> It would be nice if osg could load directly out of .blend files, but the
>> code in blender that deals with the file format is huge.
>>
>> Maybe somebody who is particularly bored could have a go at
>> refactoring the .blend
>> code into a separate library.
>
> Again, this exists already, even though you probably do not want to do it. The
> .blend files are more containers of a lot of different things than a scenegraph-
> like structure and the mapping will be tricky. The library is called
> "readblend" and comes with the Bullet physics engine.
Nice, thanks for the info, I'll look in to that.
I'd prefer to load models directly out of the .blend file,
it would save mucking about with exporting.
Jan Ciger
>
> Well .lwo was the first format I found that worked and it's binary so
> the models load quickly.
> The apps I work on, load lots of stuff outta dbs, run third party dlls
> & black boxes etc
> on start up, so they are already irritatingly slow to start up.
Well, you export to .osg and then you can always convert to binary .ive once
you are happy with the model.
> There's also the problem with setting up new machines to run a project;
> It takes ages to join the code co-op projects, install boost & other
> libraries, black boxes, etc, etc. Adding another step of installing
> blender and then getting
> the export script as well just makes things take longer.
Hmm, how is that different from going the .lwo route? You need Blender
installed and export to .lwo as well, no?
> Nice, thanks for the info, I'll look in to that.
>
> I'd prefer to load models directly out of the .blend file,
> it would save mucking about with exporting.
You can actually automate the export - e.g. the Soya3D engine does it in that
way that whenever the user requests a .blend file to be loaded, it spawns
Blender in the background calling it with a command line argument to load the
model and call the export script. The result is then cached and the model is
re-exported only when the .blend file is newer than the cached data. The user
never has to tinker with the exporter, they just notice Blender starting once
when the model is exported for the first time.
Jan
Simon Hammett
> Simon Hammett <s.d.h...@googlemail.com> wrote:
>>
>> Well .lwo was the first format I found that worked and it's binary so
>> the models load quickly.
>> The apps I work on, load lots of stuff outta dbs, run third party dlls
>> & black boxes etc
>> on start up, so they are already irritatingly slow to start up.
>
> Well, you export to .osg and then you can always convert to binary .ive once
> you are happy with the model.
which is yet another step in the process.
that's making things more complicated, not less.
and .lwo works rather nicely so why change?
>> There's also the problem with setting up new machines to run a project;
>> It takes ages to join the code co-op projects, install boost & other
>> libraries, black boxes, etc, etc. Adding another step of installing
>> blender and then getting
>> the export script as well just makes things take longer.
>
> Hmm, how is that different from going the .lwo route? You need Blender
> installed and export to .lwo as well, no?
yes, but you don't have to hunt up the osg exporter script and install that.
again, it's adding yet another step the process.
>
>> Nice, thanks for the info, I'll look in to that.
>>
>> I'd prefer to load models directly out of the .blend file,
>> it would save mucking about with exporting.
> You can actually automate the export - e.g. the Soya3D engine does it in that
> way that whenever the user requests a .blend file to be loaded, it spawns
> Blender in the background calling it with a command line argument to load the
> model and call the export script. The result is then cached and the model is
> re-exported only when the .blend file is newer than the cached data. The user
> never has to tinker with the exporter, they just notice Blender starting once
> when the model is exported for the first time.
>
> Jan
Well I could do that on my development machine, but I'm not going to
take that route
for client machines.
Sometimes our apps are rolled out to many hundreds of machines;
am I supposed to ask them to install blender, install the export
script, then install our app
x 700 times? That's just not going to fly.
Exporting to .lwo is easy and if that readblend library you mentioned
is a viable route then
I can simplify things by removing another job that I have to do.
btw, do you have any xp with that library?
I'd much appreciate any thing extra you can tell me about it.
Jan Ciger
> which is yet another step in the process.
> that's making things more complicated, not less.
> and .lwo works rather nicely so why change?
Because .osg can capture also things that are native to the scenegraph that
you cannot capture in .lwo (e.g. shaders). Moreover, the compiled .ive is
optimized by the OSG optimizer, saving even more loading time.
> Sometimes our apps are rolled out to many hundreds of machines;
> am I supposed to ask them to install blender, install the export
> script, then install our app
> x 700 times? That's just not going to fly.
Then you are doing it wrong, in my opinion. If you are provisioning 700
machines, you should have a premade system image with all this preconfigured or
an installer that will install all the tools the user needs in one go (Blender
and the scripts are freely redistributable). Then having an extra exporter or
whatever doesn't matter.
Are you really saying that you are installing (or have the users install) 700
machines manually?? I do not know your exact situation, but this sounds rather
crazy to me.
Anyhow, I am not going to tell you how to do your job - if it works for you,
by all means stay with it.
> btw, do you have any xp with that library?
> I'd much appreciate any thing extra you can tell me about it.
No, I didn't try it, I just saw it in Bullet when I have played with it.
Regards,
Jan
Simon Hammett
> Simon Hammett <s.d.h...@googlemail.com> wrote:
>> which is yet another step in the process.
>> that's making things more complicated, not less.
>> and .lwo works rather nicely so why change?
>
> Because .osg can capture also things that are native to the scenegraph that
> you cannot capture in .lwo (e.g. shaders). Moreover, the compiled .ive is
> optimized by the OSG optimizer, saving even more loading time.
And if I needed shaders or animation I'd be using the osg export script.
Like I said, .lwo does it for me, so why add an extra step?
>> Sometimes our apps are rolled out to many hundreds of machines;
>> am I supposed to ask them to install blender, install the export
>> script, then install our app
>> x 700 times? That's just not going to fly.
>
> Then you are doing it wrong, in my opinion. If you are provisioning 700
> machines, you should have a premade system image with all this preconfigured or
> an installer that will install all the tools the user needs in one go (Blender
> and the scripts are freely redistributable). Then having an extra exporter or
> whatever doesn't matter.
>
> Are you really saying that you are installing (or have the users install) 700
> machines manually?? I do not know your exact situation, but this sounds rather
> crazy to me.
I completely agree, it is crazy.
But we sell s/w to small/medium sized manufacturing companies and that's
the way most of them do this stuff.
We try and persuade them otherwise, but it's very rare for anybody to
ever listen. And even then, our s/w isn't just used directly by the
clients, it's
distributed to their many sales reps who are independent companies of
only 1 or 2 people.
Most the of the sales reps are people who have trouble walking and talking
at the same time, so the install process has to be as simple as possible.
In the manufacturing world most companies have very small profit margins
and are therefore very reluctant to spent money and are very conservative
and as a suppler to those companies, our profits are minimal as well
unfortunately.
My development machine is over 4 years old and my monitor is over 10 years old.
But I get to do quite a bit of graphics work, so that makes up for the
other irritations.
> Anyhow, I am not going to tell you how to do your job - if it works for you,
> by all means stay with it.
I wish we wouldn't...
>> btw, do you have any xp with that library?
>> I'd much appreciate any thing extra you can tell me about it.
>
> No, I didn't try it, I just saw it in Bullet when I have played with it.
>
Ah, ty.
Cedric Pinson
Blender file is a container like 3dsmax file. If you want to load .blend
in osg directly it will be very complex and not suitable for a lot of
cases.
Anyway, if you really want it i would suggest to make a plugin that run
osg export in background mode and then load the result in osg.
Of course it depends of your usage, i use osgexport and it works very
well, do you have some problem with it ?
Cheers,
Cedric
--
+33 659 598 614 Cedric Pinson mailto:cedric...@plopbyte.net
http://www.plopbyte.net