Jump to content
The Dark Mod Forums

Merge Export To Obj Into Main Codebase


Recommended Posts

I've reorganised the brushexport plugin into a module and I'm running into a crash when this is called:

 

BrushInstance* bptr = InstanceTypeCast<BrushInstance>::cast(instance);

 

This should convert a general instance into a BrushInstance, but it crashes for some reason. Apart from this everything is in place, the module gets loaded correctly and I can successfully draw a brush and call the option from the menu. I can even select the file from the GTK dialog and as soon as the visitor class starts traversing the scene, it bails out.

 

I'm working on it (slowly, because the std::cout debugs are tedious and compile times increase as I reach the deeper include files with lots of dependencies), just wanted to post my progress here. :)

Link to comment
Share on other sites

Can't help you really, I don't understand that templated cast stuff except that it is obviously an ugly home-grown reimplementation (fancy that!) of C++'s standard dynamic_cast which does exactly the same thing using inheritance rather than silly tables of StaticTypeCasts and the like.

 

The only thing I can suggest is make doubly sure that your visit function is being passed what you expect. Maybe it is also being passed instances of something else which cannot be cast in that way.

Link to comment
Share on other sites

Basically I think when you call SomethingTypeCast<Sometype>::cast(something) it just invokes an incredible laborious path to the function something.get(NullType<Sometype>) which returns a reference to a Sometype (which may be the object itself, like with BrushInstance although some objects return a contained object here).

 

Even if you didn't want to use dynamic_cast, you could have an interface Castable which would define a pure virtual cast() function for the object to implement, but then this would spoil all the templated fun. EDIT: Actually no you couldn't, because it would need a covariant return type. You'd probably have to do some templating, but I can't see it needing to be as complex as it is.

Link to comment
Share on other sites

Sorry, can't follow you, but this is most probably me being too tired at the moment.

 

Well, at least I could figure out why the thing's crashing: there is this member variable TypeCast m_casts; in class TypeCastTable. And the method cast() gets called with exactly SIZE as index, which is perfectly out of bounds and this is where it crashes.

 

I just implemented a bounds check, but I don't know if this is leading anywhere...

 

What the heck is this for?

typedef void*(*TypeCast)(void*);

Link to comment
Share on other sites

Sorry, can't follow you, but this is most probably me being too tired at the moment.

 

If you look at BrushInstance you will see there is a method get(NullType<BrushInstance>). This is what gets eventually called when you cast an Instance to a BrushInstance using the templated cast system.

 

Well, at least I could figure out why the thing's crashing: there is this member variable TypeCast m_casts; in class TypeCastTable. And the method cast() gets called with exactly SIZE as index, which is perfectly out of bounds and this is where it crashes.

 

I have a suspicion that you may be barking up the wrong tree with this. Convoluted as the cast system is, I don't suppose it has such glaring bugs as this that haven't already been discovered and fixed.

 

When you say you are converting the brush export code to a module, is this an entirely new module or are you using an existing interface such as the map export code in imap.h? Does it work better if you put the OBJ export into the main binary?

Link to comment
Share on other sites

When you say you are converting the brush export code to a module, is this an entirely new module or are you using an existing interface such as the map export code in imap.h? Does it work better if you put the OBJ export into the main binary?

I adapted the XMLRegistry Module, created a new abstract base class, created the module reference and its dependencies, instantiated the module and tested it with some std::cout

 

The problem is most probably buried somewhere here (as it's working as a plugin, it must be me :)), so as next step I intended to take smaller steps and try to create working code within the radiant core (as you suggested) and then try to move it into a module.

 

I didn't expect this thing to create such problems, the module implementation was straight forward to the point where the BrushInstance cast crashed, so I guess I took one step too large. I will look into this in the evening when I get home and I will keep you posted on my progress.

 

I'm still curious why the getTypeId function returns the value 64 (which is one too large and it's crashing on accessing the array[64]) when traversing through the scene (usual values are around 7 to 8), but I'm afraid that I won't reach the bottom of this problem.

Link to comment
Share on other sites

As another approach, you might consider instead of moving the code, improving the plugin module interface so that plugins can add menu items anywhere, rather than just in the Plugins menu. For example, when a plugin is queried for its command list, it could return an item name, icon and menu path instead of just a name.

 

This would be worth doing as it would allow more use of individual, specialised plugins that could insert their GUI entries in more places - anywhere on the main menu and in the OrthoContextMenu would be a good start. You might also find it easier than trying to move the code, and it would be an opportunity to improve the interface from the old "function pointer" style to the new "pure-virtual methods" style.

 

EDIT: Actually this would be very cool. The objectives editor and stim/response editor (and any other DarkMod stuff) could be plugins which are only loaded for Dark Mod editing and ignored for vanilla Doom3 editing.

Link to comment
Share on other sites

So how would such a plugin interface look like? Would there exist a generic iplugin.h abstract base class which defines the methods that are needed to attach the plugin to the core (like "getCommandList", "getMenuPath", "getSomething" and so on)?

 

What about Dependencies? Would they be handled like they are with the current modules?

Link to comment
Share on other sites

The plugin interface is already defined in qerplugin.h (I think) -- it is the one that the brush export plugin currently uses. I imagine that dependencies are handled like anything else, the only difference in execution is that the main binary will query each plugin for its list of commands at startup.

Link to comment
Share on other sites

Hm, ok, I will have to take a look how the current systems queries the commandlist and how it treats this information. Perhaps I can come up with something good enough so that it will be usable in those future plugins.

Link to comment
Share on other sites

I just did a quick check and put the module into radiant/brushexport, i.e. copied the code into the radiant core (commented the module stuff out), and it works like a charm. Something has to be amiss with my module implementation. Took me 3 whole minutes including compile...

 

I will now look into the plugin code.

Link to comment
Share on other sites

I found a bunch of classes in pluginmanager.h and pluginmanager.cpp that already seem to be doing some of the things you suggested. I will try to analyse this part and document these two files, so that I know more about how the pluginmanagement works.

Link to comment
Share on other sites

Sounds good.

 

One thing you could do is get the plugin manager to build a hashmap associating menu names with plugins (the plugins would return a suitable data structure indicating which commands should go in which menus). Then when the menus are constructed, each menu construction function could check in the hashmap to see if there are any plugin commands for that menu, and add them at an appropriate place.

 

Just one idea, there may be better ones.

Link to comment
Share on other sites

One thing you could do is get the plugin manager to build a hashmap associating menu names with plugins (the plugins would return a suitable data structure indicating which commands should go in which menus). Then when the menus are constructed, each menu construction function could check in the hashmap to see if there are any plugin commands for that menu, and add them at an appropriate place.

If we speak of names for menus, then we would perhaps need to reorganise the "standard" menu creation code as well (which is (of course) hardcoded at the moment). Unless I created a function like PlugInManager().getPluginMenuItems("edit"), which would return all the menu items for the "edit" menu bar, but the issue of the actual location would remain and the menu names would still be hardcoded.

 

Hm. First comes first, so I will try to document the PlugInManager for now and then look into some possibilites.

Link to comment
Share on other sites

Yes, theoretically the entire menu could be in the XML registry although I imagine converting this would be a heavy task.

 

If this were the case however, it would presumably be quite easy to have the plugins return an XPath which gets spliced into the menu structure before the menus are constructed.

Link to comment
Share on other sites

I agree, using the xpath syntax is probably a good idea.

 

We should take this into the todo list and also assign priorities to the various tasks. (I would consider the customisable menu rather a "nice to have" instead of a "must-have".)

 

The brushexport code is de facto working and nearly commitable, but not a module yet. How important is the module bit?

Link to comment
Share on other sites

The brushexport code is de facto working and nearly commitable, but not a module yet. How important is the module bit?

 

It's not a problem whether it is a plugin or a module, my main objective for the task was to allow the "Export to OBJ" item to be placed somewhere more intuitive than the Plugins menu, such as in the right-click context menu or the File menu. Whether this is done via fully-customisable menus or hardcoding is not an issue at this point.

Link to comment
Share on other sites

Ok, so for the moment being, I will move this into the radiant core (it's not very large, so it won't have much impact on build times). I also have registered a command so that it can be used in both the menus as in the customisable toolbars.

 

I will still have a look at the plugin manager code and perhaps make some additions, but at least we can tick this off the list.

Link to comment
Share on other sites

Both the BrushExportOBJ and the refactored PluginManager are committed.

 

ad BrushExportOBJ: This can be found under "Edit" now.

ad PluginManager: I split the old pluginmanager.cpp into separate files according to the class structure, removed the CopiedString stuff and the global variables as well. I also added some comments to the most important functions and classes.

Link to comment
Share on other sites

Sorry, I forgot to remove this include, commit is on the way! The compiler didn't complain that this file is missing on my system till I did a complete recompile.

 

That is an annoying thing about Scons - it doesn't pick up the deletion of an include file, so it won't recompile other files that depend on it.

Link to comment
Share on other sites

I should have thought of that before and I hope that didn't stop the show for you, I will look out for this next time.

 

I've picked up the disentangling and documentation of the selection.cpp classes and functions again, I had left this task half-finished. Hopefully I gain some insight from this that might help for the draggable light center. If not, at least the codebase is a bit cleaner than it was before...

Link to comment
Share on other sites

I should have thought of that before and I hope that didn't stop the show for you, I will look out for this next time.

 

Don't worry about it, it is easy to do and I have committed such errors in the past.

 

I've picked up the disentangling and documentation of the selection.cpp classes and functions again, I had left this task half-finished. Hopefully I gain some insight from this that might help for the draggable light center. If not, at least the codebase is a bit cleaner than it was before...

 

Sounds good. I wouldn't push too hard on the problem if it seems to be getting difficult however, it may be the case that the existing codebase doesn't support what we need to do and will require a redesign.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...