Am I allowed to use Constructor for my own game engine?
by Dylan Wilson · in Constructor · 01/25/2010 (8:37 am) · 8 replies
Is there any restrictions on using Torque Constructor to build maps for my own game engine?
I noticed that the DIF file format specification is available on the wiki. I'd like to write an importer for my own game engine that I've built using Ogre, PhysX, OpenAL and OIS.
I bought the Torque engine a couple of years ago and it doesn't really suit my needs at the moment. Although, I would be interesting in purchasing some of the art packs and other add-ons.
I noticed that the DIF file format specification is available on the wiki. I'd like to write an importer for my own game engine that I've built using Ogre, PhysX, OpenAL and OIS.
I bought the Torque engine a couple of years ago and it doesn't really suit my needs at the moment. Although, I would be interesting in purchasing some of the art packs and other add-ons.
#2
Nope, no such restrictions with Constructor. The EULA is available on Constructor's product page here.
01/25/2010 (12:09 pm)
Nope, no such restrictions with Constructor. The EULA is available on Constructor's product page here.
#3
01/25/2010 (1:51 pm)
My thought was similar to Steve's. Why not write a Q3 importer and use Radiant? Of course, you could not use any of the GPL'd code unless you wanted to release your project under the GPL. But there's ample code resources out there on loading Q3 maps.
#4
I did read the EULA before I posted on the forums, I just wanted to double check.
I'm not a big fan of the Radiant interface and I had a number of problems running it on my machine without linking it to an existing game engine.
I certainly considered many options and even started writing my own editor from scratch. This was going well until I realised I had to write a lightmapper. I know that writing an editor is a huge task but what I did manage to get done in a few weeks works really well. I may still finish it in the future because I have a lot of ideas on how to improve on existing options. I also believe there is a market for such a thing.
At the moment I'm just looking at my other options.
01/26/2010 (7:08 am)
Thanks for the replies guys.I did read the EULA before I posted on the forums, I just wanted to double check.
I'm not a big fan of the Radiant interface and I had a number of problems running it on my machine without linking it to an existing game engine.
I certainly considered many options and even started writing my own editor from scratch. This was going well until I realised I had to write a lightmapper. I know that writing an editor is a huge task but what I did manage to get done in a few weeks works really well. I may still finish it in the future because I have a lot of ideas on how to improve on existing options. I also believe there is a market for such a thing.
At the moment I'm just looking at my other options.
#6
It's a shame they can't be controlled via an SDK or command line though, that way I could integrate it into my editor rather than having to export and import all the time.
There's only a handful of articles on implementing lightmapping. I've had a go and I think I have the theory clear in my head. I was just not expecting to have to do so much work in this area :)
01/26/2010 (7:52 am)
Yeh, I've looked into gile[s] and a few other stand alone light mappers. It's a shame they can't be controlled via an SDK or command line though, that way I could integrate it into my editor rather than having to export and import all the time.
There's only a handful of articles on implementing lightmapping. I've had a go and I think I have the theory clear in my head. I was just not expecting to have to do so much work in this area :)
#7
The problem I see with the do-it-yourself approach to lightmapping is that a ton of people out there have walked down that path leaving a ton of crappy direct lighting-only mappers in their wake.
IMO if one really wants to make lightmapping worth it nowadays (as you can get quite a bit of solid direct lighting in real-time on todays computers), it really has to be way better than the direct lighting a real-time engine can provide. And that means a solid global illumination solution--which ups the effort that has to go into it quite a bit.
01/26/2010 (8:05 am)
The problem I see with the do-it-yourself approach to lightmapping is that a ton of people out there have walked down that path leaving a ton of crappy direct lighting-only mappers in their wake.
IMO if one really wants to make lightmapping worth it nowadays (as you can get quite a bit of solid direct lighting in real-time on todays computers), it really has to be way better than the direct lighting a real-time engine can provide. And that means a solid global illumination solution--which ups the effort that has to go into it quite a bit.
#8
Unfortunately, the only one I can find is LightSprint which seems to be targeted at larger game companies with big budgets.
Google also pulls up Radium SDK but it appears that it no longer exists.
I know that there are many 3D modelling programs that implement lightmappers already, but that's all the more reason why I should be able to implement one in my own editor. It may not be a full radiosity mapper, but it would reduce the overhead of full dynamic lighting which is kind of the point.
01/26/2010 (8:40 am)
I totally agree with what your saying here, which is why it makes sense to use SDK's or other existing libraries.Unfortunately, the only one I can find is LightSprint which seems to be targeted at larger game companies with big budgets.
Google also pulls up Radium SDK but it appears that it no longer exists.
I know that there are many 3D modelling programs that implement lightmappers already, but that's all the more reason why I should be able to implement one in my own editor. It may not be a full radiosity mapper, but it would reduce the overhead of full dynamic lighting which is kind of the point.
Associate Steve Acaster
[YorkshireRifles.com]
Doesn't GTKRadiant come with a some sort of GNU license?