http://www.torquepowered.com/community/resources/view/15039

There is already a resource for it :r

+ I'm not talking about editing the engine for our needs I'm talking about adding to it with DLLs.
KermMartian wrote:
jimmg wrote:
[video]
Now you're thinking with POR-TALS.


More like TARDISes.

KermMartian wrote:
Anywho, getting back on topic, you won't be able to hook DLLs into the engine, but you will be able to use TorqueScript via DynLoad.

Pretty much this, but not for exactly the reasons that Kerm says. I could probably be able to release header information for external modules to compile AGAINST and be within the bounds of my license (even if it would be semi-annoying to set up). Having compiled binary modules adds a whole new level of safety issues for users when installing mods, and makes it much more difficult to keep things open source and cross platform. As far as I know, there is nothing keeping you from writing your own OpenSceneGraph Nodekits to implement whatever rendering behavior you want, and nothing keeping you from scripting whatever gameplay behavior you want, but I won't be providing interfaces to link against Torque classes.


Jimmg wrote:
An example would be if a server needed a edit of the engine for a flying player class they could just hook in with their DLL and do it themselves.

We already have a flying player class (soon to be with 6DoF movement when flying)? And we'll have a real physics engine too?
elfprince13 wrote:

Jimmg wrote:
An example would be if a server needed a edit of the engine for a flying player class they could just hook in with their DLL and do it themselves.

We already have a flying player class (soon to be with 6DoF movement when flying)? And we'll have a real physics engine too?

It was just an example, but I wasn't aware torque had a flying player class. Though if you mean just jetting, that isn't what i'm talking about. I'm talking about birds and things.
elfprince13 wrote:

KermMartian wrote:
Anywho, getting back on topic, you won't be able to hook DLLs into the engine, but you will be able to use TorqueScript via DynLoad.

Pretty much this, but not for exactly the reasons that Kerm says. I could probably be able to release header information for external modules to compile AGAINST and be within the bounds of my license (even if it would be semi-annoying to set up). Having compiled binary modules adds a whole new level of safety issues for users when installing mods, and makes it much more difficult to keep things open source and cross platform.
Couldn't you have a rule set up so the module creators had to put their source code? Maybe have a system where you review them before they're posted?
Jimmg wrote:

It was just an example, but I wasn't aware torque had a flying player class. Though if you mean just jetting, that isn't what i'm talking about. I'm talking about birds and things.

It doesn't have one by default, but the changes I am making to it will allow there to be one pretty easily. 6DoF means 6 degrees of freedom. I'd be big fan of stomping/soaring around a medieval DM as a Lego Dragon.

Jimmg wrote:
Couldn't you have a rule set up so the module creators had to put their source code? Maybe have a system where you review them before they're posted?

Requiring that modules be open sourced is fine and dandy, but we honestly don't have the time to review modules the same way we do other mods, largely because the worst a TorqueScript could do is trash the contents of the Torque sandbox, whereas the really isn't a limit to the worst a .dll can do. If you write something like a NodeKit for osg, it potentially has the same destructive power, but it is much easier to scan the source code for things it shouldn't be doing. i.e., deleting things from the file system instead of setting OpenGL states.

And honestly, if there's something you REALLY want that you just can't do with the tools we're providing, you should just make a feature request.
If you have a torque license, you can get the engine code to play with if you want...
DShiznit wrote:
If you have a torque license, you can get the engine code to play with if you want...

If you have a Torque License you are actively encouraged to help with the engine.


elfprince13 wrote:
actually....if you (or anyone) really want to help with algorithms, it would be possible to start modifying the OpenSceneGraph renderer to make use of CHC++ without access to any of the Torque engine code. That would be a significant undertaking, but CHC++ example source code is available here, and the paper describing it is here.

OSG can be downloaded from here and an intro to programming with OSG is here, including important concepts like StateSets, NodeVisitors, and (I think) multiparented nodes.

This is probably the only one of the 3 potentially significant undertakings before the overhauled engine is ready that can be done without access to the TGE code. It is also worth mentioning that I suspect this algorithm will go a long way towards cutting the poly-count down, as far as stud/tube primitives are concerned. I *think* because the stud/tube geometry is stored in a separate node from the brick outline, they should be treated as occluded by the bounding volume of the brick above them, and that because this information will tend to be static, the algorithm's exploitation of temporal coherency should allow it to cache that information and save on both occlusion queries and a huge number of polygons. I may email the authors of the paper to double check that a bounding volume within a larger bounding volume will be treated as occluded by the larger.

This NodeKit may also make a useful reference for anyone wishing to attempt this, in order to see how occlusion queries can be done with OSG. Obviously this isn't the algorithm we want, but it does provide a simple example.
Does your license allow you to "employ" other people who don't have individual licenses to work on your engine that you release?
DShiznit wrote:
Does your license allow you to "employ" other people who don't have individual licenses to work on your engine that you release?


No, unfortunately indie licenses are seat licenses, not site licenses.
elfprince13 wrote:
DShiznit wrote:
If you have a torque license, you can get the engine code to play with if you want...

If you have a Torque License you are actively encouraged to help with the engine.
Perhaps we could even word it as strongly as:
If you are reading this and have a Torque License you are required to help with the engine?
That would be nice Smile


also,


Code:
 osgviewer -l ../Plugins/osgdb_bsp.so  ~/tbgblstuff/freebuild/trunk/mods/castle/data/interiors/elfprince/fortress/firebreathingfortress_hi.dif
File Resource Version44
LOD COUNT 1
File Version14
a state?0 nlightstateentries 0
reading 299 normals
reading 4507 points
reading 4506 point vis states
reading 1974 texGenEQs
Huzzah! OSG + a DIF! How does it look rendered, or am I jumping the gun again?
Still jumping the gun. There is still a huge amount of information I have to read from it. I was just posting this to show I was making progress even in the midst of my super hectic week.
elfprince13 wrote:
Still jumping the gun. There is still a huge amount of information I have to read from it. I was just posting this to show I was making progress even in the midst of my super hectic week.
Ah, then pardon me, but still stunningly awesome. Smile Thanks for your dedication even when you're busy with real life; on behalf of all the current and future Freebuild players, I solicit our gratitude.

Code:
File Resource Version44
LOD COUNT 1
File Version14
a state?0 nlightstateentries 0
reading 299 normals
reading 4507 points
reading 4506 point vis states
reading 1974 texGenEQs
reading 5046 IBSPNodes
reading 2489 IBSPSolidLeaves
read 16 material names
reading 11029 windings
reading 1 TriFans (winding indices)
reading 7426 edges
reading 3 zones
reading 2732 zone surfaces
reading 15 zone static meshes
reading 1 entries into zonePortalList
reading 1 portals
reading 2747 surfaces and lmTexGenEQs

osgviewer: No data loaded

So, at least in theory, I am no reading in all the data I need to display a the geometry for a single LOD in a dif file, but unfortunately I need to read quite a bit more data (that will come in useful later for things like collisions, culling, etc) to loop through a dif with multiple LODs.
Very awesome, elfprince! Keep up the great work, and let me know anything I can help out with other than keeping up the forum end of things.
KermMartian wrote:
Very awesome, elfprince! Keep up the great work, and let me know anything I can help out with other than keeping up the forum end of things.

I don't know if this interests you, but did you see my mention of the portions of coding that could be done with only access to opensource components of the engine a little ways back?

[edit]

Grawr. I made some changes and got the loading working up through the null surfaces. I've checked that the values are correct against the Torque implementation, and can verify that even the number of light maps to be read is working, however trying to read a png from the stream using osgDB methods seems to be raising a bus error, and I'm really not looking forward to debugging code on that sort of low level. Perhaps I can just bring in readPng method from Torque in some form or another. We'll see how it goes.

Code:
reading 2747 normal LMap indices
reading 2747 alarm LMap indices
reading 31 null surfaces
reading 20 lightmaps and lightDirMaps and lightmapkeeps
Bus error
elfprince13 wrote:
KermMartian wrote:
Very awesome, elfprince! Keep up the great work, and let me know anything I can help out with other than keeping up the forum end of things.

I don't know if this interests you, but did you see my mention of the portions of coding that could be done with only access to opensource components of the engine a little ways back?
I most certainly did, but I'm quite chagrined to say with the amount of code and homework I have to write for research and class, I don't quite have the time for something that intense. Sad Sorry.

Quote:
[edit]

Grawr. I made some changes and got the loading working up through the null surfaces. I've checked that the values are correct against the Torque implementation, and can verify that even the number of light maps to be read is working, however trying to read a png from the stream using osgDB methods seems to be raising a bus error, and I'm really not looking forward to debugging code on that sort of low level. Perhaps I can just bring in readPng method from Torque in some form or another. We'll see how it goes.

Code:
reading 2747 normal LMap indices
reading 2747 alarm LMap indices
reading 31 null surfaces
reading 20 lightmaps and lightDirMaps and lightmapkeeps
Bus error
How frustrating! I hope you figure out a workaround or a fix.
KermMartian wrote:
I most certainly did, but I'm quite chagrined to say with the amount of code and homework I have to write for research and class, I don't quite have the time for something that intense. Sad Sorry.
I was relatively sure that was the case, but I thought I'd double check. If anything less time-consumptive comes up, I'll let you know.


Quote:
How frustrating! I hope you figure out a workaround or a fix.

As do I. I'm not looking forward to debugging this.
elfprince13 wrote:
KermMartian wrote:
I most certainly did, but I'm quite chagrined to say with the amount of code and homework I have to write for research and class, I don't quite have the time for something that intense. Sad Sorry.
I was relatively sure that was the case, but I thought I'd double check. If anything less time-consumptive comes up, I'll let you know.
Excellent, thanks. Smile

Quote:
Quote:
How frustrating! I hope you figure out a workaround or a fix.

As do I. I'm not looking forward to debugging this.
Do you have any proposed ways to test? Are there any debuggers you could attach to track the SIGBUS? GDB? Razz
KermMartian wrote:
Do you have any proposed ways to test? Are there any debuggers you could attach to track the SIGBUS? GDB? Razz

Well I have osgviewer + my plugin running inside of Xcode's GDB environment, but the crash disappears into some image loading code (without debugging symbols) in a quicktime library in the ReaderWriterQT plugin which provides the default image reader for OSG under OS X. Given that I can show I've read the stream correctly up until that point, and some information provided in response to my topic here, it's likely I'm encountering a bug in the code that interfaces between OSG and quicktime's API. It's likely that I can force things to load through a libpng-based plugin instead, but I still have to add this to my project, get it compiling, and figure out how to force the plugin registry to load that in favor of Quicktime.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5 ... 11, 12, 13  Next
» View previous topic :: View next topic  
Page 4 of 13
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement