Author Topic: Nevercheetah3d (WIP)  (Read 2883 times)

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Nevercheetah3d (WIP)
« Reply #15 on: March 10, 2015, 08:31:43 pm »


               

Question 7:


Do nodes always have unique names? And are they always recorded after their parents in the mdl file?



node trimesh Cylinder
  parent 1test

I am working on my importer script, and decided to perform operations (creation and modification of actual objects in Cheetah3d) according to each line of the file as I read it in.


 


As you can see I'm currently dealing with setting the parent of a node. Given the mdl data above when I reach the "parent" declaration, I look through all existing objects named "1test" that I've created in my Cheetah3d scene. The first match I find gets returned and becomes the proud new parent of the node I last created.


 


If the answer to either of my questions above is "no", I will need to put some serious thought into how I handle this (perhaps read the entire mdl file in all at once, and use various string parsing functions on that data rather than execute the code of the mdl immediately).


 


___


My find Node by name code



function getNodeByName(name,mdl_base)
{
  // create a check list of nodes to check
  // start with the mdl_base
  var check_list  = [mdl_base];

  while(check_list.length>0)
  {
    // start with the last index of the array of nodes to check
    var node = check_list.pop();
    // check its name
    if(node.getParameter('name')==name)
      return node;
    // add its children to the array of nodes to check
    for(i=0;i<node.childCount();i++)
      check_list.push(node.childAtIndex(i));
  }

  return null;
}


               
               

               
            

Legacy_MerricksDad

  • Hero Member
  • *****
  • Posts: 2105
  • Karma: +0/-0
Nevercheetah3d (WIP)
« Reply #16 on: March 10, 2015, 09:05:34 pm »


               

node names are not always unique. While I shouldn't, I commonly have multiple generic meshes or dummies named the same in some models. It doesn't seem to cause any issues.


 


nodes listed in the file should always come after their parent node details, just like c# headers should always appear somewhere above actual function definitions.


 


If the javascript you can use in that program is the full kit, as used in browsers, and specifically has prototype modifiers, feel free to peek and poke at my javascript libraries online. Use anything you like.


 


https://greasyfork.o...on-library/code



               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Nevercheetah3d (WIP)
« Reply #17 on: March 10, 2015, 09:39:47 pm »


               

Hmmmm..... *musing* if a MDL will accept nodes of the same name, then I suspect that the nearest node above the current with the parent name is the parent node. I should be able to work with that, and I'll double check my export code to ensure that that is how I generate the MDL file.


 


As far as the javascript in this modeller, yes, it is using javascript from webkit. I haven't found anything missing yet. Only changes that I have found involve the API for the modeller. Thanks for sharing your code. I'll see if I can make use of it.



               
               

               
            

Legacy_Michael DarkAngel

  • Hero Member
  • *****
  • Posts: 627
  • Karma: +0/-0
Nevercheetah3d (WIP)
« Reply #18 on: March 10, 2015, 10:25:41 pm »


               

While having non-unique names for child nodes doesn't seem to cause an issue, having non-unique names for parent nodes in the same model may or may not cause some issues in-game (not sure, never tested it).  In an importer it would definitely create some havoc.  I can't recall ever seeing this happen.  We should test it and see what happens ':blink:'


 


I do remember that in NWN2 if every object in a scene was not uniquely named it would cause problems.  [EDIT]Actually, that's not the correct way to state that.  Multiples of the same model will have objects that are named alike.  So, it might be better to say that no two models could have objects named alike.[/EDIT]


 


icon_zdevil.gif


MDA



               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Nevercheetah3d (WIP)
« Reply #19 on: March 12, 2015, 05:00:00 am »


               

I've hit a wall with this because Cheetah's API has some limitations with regards to materials. The material node system does not have an API for me to access via scripts. The developer is working on this though and so once I have access to the materials I shoul dbe back in business with my importer script. (I need to be able to create materials and apply them to the objects I am importing.)



               
               

               
            

Legacy_OldTimeRadio

  • Hero Member
  • *****
  • Posts: 2307
  • Karma: +0/-0
Nevercheetah3d (WIP)
« Reply #20 on: March 12, 2015, 05:55:10 am »


               

If you're looking for something to tinker with, Java-wise, might I suggest the NWN 3D Java Model viewer as fodder?  That came with the source code and I'd uploaded both the program and the source code to the old Vault.  Not sure where it is at the new one but I assume it made it there. (?)


 


The reason I bring it up is, after all these years, NWN still doesn't have a good emitter creation program where you edit how they look, real-time.  The model viewer does a good job displaying most types of emitters, already.  I have no idea what kind of work would be involved in adding that extra functionality (sliders and checkboxes to tweak emitters and be able to export them) but it would be so much nicer than doing it by hand.  Barring those specific changes, any functionality you saw fit to add would almost certainly be appreciated.


 


Anyway, just a thought.  Cheers!



               
               

               
            

Legacy_Michael DarkAngel

  • Hero Member
  • *****
  • Posts: 627
  • Karma: +0/-0
Nevercheetah3d (WIP)
« Reply #21 on: March 12, 2015, 06:03:04 am »


               


I've hit a wall with this because Cheetah's API has some limitations with regards to materials. The material node system does not have an API for me to access via scripts. The developer is working on this though and so once I have access to the materials I shoul dbe back in business with my importer script. (I need to be able to create materials and apply them to the objects I am importing.)




 


You're right.  Without the ability to create and apply a material via scripting it does limit how complete your importer will be.  Having said that, however, should not stop you from making your importer as complete as it can be.  You can leave yourself a couple of comments in the code where you want the material creation to take place and then move on to the next step of what you want the importer to accomplish.


 


Never stop working on something because you hit a wall, hurdle that wall and continue on so that you can come back later and knock it down with ease.


 


If by some chance it takes the developer longer than anticipated, you may lose the desire to pick up where you left off.


 


icon_zdevil.gif


MDA


               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Nevercheetah3d (WIP)
« Reply #22 on: March 12, 2015, 03:49:35 pm »


               

I didn't stop actually because i have a hard time letting go of a project. But that said, the awesome dev of Cheetah just gave me the documentation on the API I needed so… its already coded, just undocumented. '<img'>


 


I'm doubling back to materials now, after I finish my bit on mesh import. Implementing the file one piece at a time with each line in the file turns out not to be a great method since I want to gnerate all of the faces after I create all of the verts and tverts….. working on that fix now.


 


that said, once this is done, and i have had my fill with blender. i'll look at that java thing. '<img'>



               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Nevercheetah3d (WIP)
« Reply #23 on: March 16, 2015, 02:47:49 pm »


               

Made slow progress this week, but figured out materials, and am working on refactoring my code so that this tool can work in all ways I want it to: import, export, setup any new file in cheetah to work as a NWN mdl. and then other little tools/helpers.


 


doing this required that I figure out how to reuse my code in WebKit's JavaScript environment which disallows "require", a kind of include. I am basically executing my include script (eval() ) as a work around.



// name space for MDL functions
var MDL = {};

// load and execute external code
function loadLibrary(prepath,libraryName)
{
   var file = new File(prepath+"Library/Application Support/Cheetah3D/Scripts/Library/" + libraryName);
   file.open(READ_MODE);
   var funcstring = file.read(file.size());
   file.close();
   eval(funcstring);
}

function loadIncludes(caller)
{
  var prepath = caller.scriptPath().match(/(\/Users\/[-\w^&'@{}[\],$=!#().%+~ ]*\/)/g);
   loadLibrary(prepath,"math_extension.js");
   loadLibrary(prepath,"mdl.js");
}


               
               

               
            

Legacy_Zwerkules

  • Hero Member
  • *****
  • Posts: 1997
  • Karma: +0/-0
Nevercheetah3d (WIP)
« Reply #24 on: March 16, 2015, 10:36:51 pm »


               


While having non-unique names for child nodes doesn't seem to cause an issue, having non-unique names for parent nodes in the same model may or may not cause some issues in-game (not sure, never tested it).  In an importer it would definitely create some havoc.  I can't recall ever seeing this happen.  We should test it and see what happens ':blink:'




Child nodes with the same name are okay, but parent nodes (especially dummies) cause problems when you import more than one model. For example Clean Models 3 creates a dummy called cm3repair if the animation node of a tile is not at 0,0,0. If you load two models which have this cm3repair dummy the children linked to cm3repair of the second model will be linked to cm3repair of the first one.



               
               

               
            

Legacy_Rolo Kipp

  • Hero Member
  • *****
  • Posts: 4349
  • Karma: +0/-0
Nevercheetah3d (WIP)
« Reply #25 on: March 18, 2015, 05:52:25 pm »


               

<scrounging around...>


 




If you're looking for something to tinker with, Java-wise, might I suggest the NWN 3D Java Model viewer as fodder?  That came with the source code and I'd uploaded both the program and the source code to the old Vault.  Not sure where it is at the new one but I assume it made it there. (?)




Sorry about the lag...


 


That's actually in my jNwN sources folder along with PSpeed's  and Abie's asset loaders, both of whom have given permission to extrapolate from their code.


 


<...in other people's rubbish bins>



               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Nevercheetah3d (WIP)
« Reply #26 on: July 11, 2015, 06:50:10 am »


               

Oh wow. in the tumult of all the balls I have in the air I forgot about this one. I might get back to this in August or try to release what I have. Just bumping this for myself as a reminder of all the loose ends I need to tie off here so that I can move forward with something else.