MtI rev 14 20 oct 2007
just want to point out finally that the current todo is quite unfair about one point: bkircher did instancing, I allowed to create a lot of instances in one click that's it k I'll do my part !
edit sorry my brain is buzzing around ! I think I have a simple fix for camera, keep it 1 node all the way and make the exporter convert it to 3 nodes at the right time. the distortion misorietation stuff is because of the camera up node only when user breaks orthogonality, maybe we can force up vector, or it should be recomputed at export time. Therefore converting the camera at export time is simple and reliable. Camera should be identified with a prefix. cheers - stop ooops not quite
Another issue with camera is scene units, where 1 unit = 1 meter. 3 nodes cameras are totally uncontrolable here if not cm, thoughts ?
edit sorry my brain is buzzing around ! I think I have a simple fix for camera, keep it 1 node all the way and make the exporter convert it to 3 nodes at the right time. the distortion misorietation stuff is because of the camera up node only when user breaks orthogonality, maybe we can force up vector, or it should be recomputed at export time. Therefore converting the camera at export time is simple and reliable. Camera should be identified with a prefix. cheers - stop ooops not quite
Another issue with camera is scene units, where 1 unit = 1 meter. 3 nodes cameras are totally uncontrolable here if not cm, thoughts ?
obsolete asset
if you're using the TortoiseSVN, right click, on a file or folder choose "TortoiseSVN -> Get Lock".
It'll ask you for a reason you locked, and list the files you are locking. Also you can "steal" a lock if someone has forgotten to release theirs
Enter credentials, and the file(s) are locked to you to work on.
As for merging your revisions - that is still up to the devs to be careful that you don't overwrite** previous changes - which is why I think it'd be a good idea to use the locking features and not do any "stealing".
When you choose to commit your changes, it'll show the files which you have modified and you can double click these to compare with what's in the current revision. Worth checking here before you commit that nothing has changed in the repo while you were hacking.
I wouldn't worry too much about the possibility of overwriting changes though because:
** SVN actually keeps a complete history for every file in the repository. If new changes are accidentally lost, we _can_ get the previous version back if necessary. (the "Update to revision" feature; type in the revision number you want and that's what gets downloaded.).
SVN also can create "tagged" versions in the repo that are always available - i.e. we can create "tags" (snapshots) for released versions, and these are always available in the repository regardless of whether further changes have been made in the main trunk.
a new dev thread might be a good idea... or keep it here. doesn't matter much.
I have a feeling that not every SVN revision will need to be released - it's probably only worth packaging up and posting a copy here after major revisions (maybe release shortly after indigo releases?).
For example, the version i released in this thread was #14, but the repo already has #25, and the functionality of the exporter has barely changed.
Advanced users can always do their own SVN checkout (which is anonymous, anyone can do it) if they wish to stay on the bleeding edge.
It'll ask you for a reason you locked, and list the files you are locking. Also you can "steal" a lock if someone has forgotten to release theirs
Enter credentials, and the file(s) are locked to you to work on.
As for merging your revisions - that is still up to the devs to be careful that you don't overwrite** previous changes - which is why I think it'd be a good idea to use the locking features and not do any "stealing".
When you choose to commit your changes, it'll show the files which you have modified and you can double click these to compare with what's in the current revision. Worth checking here before you commit that nothing has changed in the repo while you were hacking.
I wouldn't worry too much about the possibility of overwriting changes though because:
** SVN actually keeps a complete history for every file in the repository. If new changes are accidentally lost, we _can_ get the previous version back if necessary. (the "Update to revision" feature; type in the revision number you want and that's what gets downloaded.).
SVN also can create "tagged" versions in the repo that are always available - i.e. we can create "tags" (snapshots) for released versions, and these are always available in the repository regardless of whether further changes have been made in the main trunk.
a new dev thread might be a good idea... or keep it here. doesn't matter much.
I have a feeling that not every SVN revision will need to be released - it's probably only worth packaging up and posting a copy here after major revisions (maybe release shortly after indigo releases?).
For example, the version i released in this thread was #14, but the repo already has #25, and the functionality of the exporter has barely changed.
Advanced users can always do their own SVN checkout (which is anonymous, anyone can do it) if they wish to stay on the bleeding edge.
Not sure I'm right to watch here only for news, have you updated the svn repository bkircher ?
Concerning rotation matrices, I've been a bit lazy these days but I finally copied the pseudocode on my computer; that should be ready and running for monday.
Please give feedback in the forums when you do some important update, I was kinda waiting till now...
Cheers
Concerning rotation matrices, I've been a bit lazy these days but I finally copied the pseudocode on my computer; that should be ready and running for monday.
Please give feedback in the forums when you do some important update, I was kinda waiting till now...
Cheers
obsolete asset
I've just commited an update to SVN, and it would be great if that code could be checked / added to...
I've added phongE support that it now acts as a container whose
comment (the .notes attribute) is directly passed to indigo. By using certain
keywords, some phongE or global values can be passed to the shader.
Apart from that, I've seperated the shader-generating code and put it into a new mel-file, same as with the camera.
And I've added more presets, also with the blinn-stuff for translucent/transparent materials, I'm lost. Maybe someone can check into the matter.
I think it's up to Dougal to break out a given version and post it, what do you think?
to Dougal:
Would be great if we could iron out any mistakes with the simple version,
with the intention of presenting a new, stable mti, or take the current status and distribute it parallel to SVN to check what the feedback is.
to Ctzn:
Hope SVN works for you, and great that you have a look into matrices.
I've added phongE support that it now acts as a container whose
comment (the .notes attribute) is directly passed to indigo. By using certain
keywords, some phongE or global values can be passed to the shader.
Apart from that, I've seperated the shader-generating code and put it into a new mel-file, same as with the camera.
And I've added more presets, also with the blinn-stuff for translucent/transparent materials, I'm lost. Maybe someone can check into the matter.
I think it's up to Dougal to break out a given version and post it, what do you think?
to Dougal:
Would be great if we could iron out any mistakes with the simple version,
with the intention of presenting a new, stable mti, or take the current status and distribute it parallel to SVN to check what the feedback is.
to Ctzn:
Hope SVN works for you, and great that you have a look into matrices.
- Attachments
-
- IndigoScreenshot.jpg (79.69 KiB) Viewed 3448 times
Erm... the tool menu is void, is that ok ?
Obviously I misevaluated the time I'll need to implement rotation matrices: I got to get used with the simple version, then will add previous upgrades I did, will commit that and then work on RM.
I've got some questions about svn but they will come in time.
Cheers
Obviously I misevaluated the time I'll need to implement rotation matrices: I got to get used with the simple version, then will add previous upgrades I did, will commit that and then work on RM.
I've got some questions about svn but they will come in time.
Cheers
obsolete asset
What is $transform +".mti_UseExactName" for ? I've got hard time exploring uncommented code/undocumented attributes.
New sun integrated, massive instanciation on hold because of <see first sentence>, now switching to other mods I did on 7.2. Will commit before starting rotations. Feel lonely
New sun integrated, massive instanciation on hold because of <see first sentence>, now switching to other mods I did on 7.2. Will commit before starting rotations. Feel lonely
obsolete asset
i'm just going to do a quick test of rev30.
I've already updated SVN with rev31 - basically just removed a few files
1. the old /CopyTo_* folders
2. a few textures that were somehow left in the new MtISimple/CopyTo_Indigo/textures folder.
please try not to upload unnecessary files, like objs or textures
I've already updated SVN with rev31 - basically just removed a few files
1. the old /CopyTo_* folders
2. a few textures that were somehow left in the new MtISimple/CopyTo_Indigo/textures folder.
please try not to upload unnecessary files, like objs or textures
just commited rev32:
updates:
changed default render settings to match default inifile.txt
bug fixes:
substitute | for - in .obj filenames
threads: set to 0 for auto, else auto_choose_num_threads is overridden.
known issues:
can we override overwrite promtp on obj export?
/BELOWNORMAL not working?
edit: released in new thread.
updates:
changed default render settings to match default inifile.txt
bug fixes:
substitute | for - in .obj filenames
threads: set to 0 for auto, else auto_choose_num_threads is overridden.
known issues:
can we override overwrite promtp on obj export?
/BELOWNORMAL not working?
edit: released in new thread.
Who is online
Users browsing this forum: No registered users and 15 guests