i would go for memory conservation and rendering speed since thats what i use the program for ahaha, adding stuff to the program might make it too cluttered imo , the viewer is fine imo , but people might want more neat effects dunno . Cant wait to see what you are cooking santi
Of course improved speed and reduced memory is always good,
I think that a more standard windows style UI would be great, it feels kinda weird and unnecessary the way the whole app is set up at the moment.
I think it'd be nicer just to put the current pages into a standard windows tab arrangement.
I really thing memory consumption and rendering speed is the most important thing and should be the focus, because honestly thats about 99% of what i'm using it for.
It might be nice to have a more standard UI, i dont even really see the need to make it customizable, just having a more standard look. That being said i'm used to the UI and wouldnt complain if you spent all of your time just making speed/memory improvements and did nothing else on the list here.
Agreed. I still use XSI just because I can squeeze a few more polygons into my bakes, meaning less breaking things up. Of course, you forgot to add the 'all of the above' option. =D
I've to agree with MoP on this. I'm found of this tool but the design looks kinda funky atm. It deserves a professional look I personally choose the 3D viewer effects because I really would like to have Xnormal as my official screenshot/presentation maker. BUT the custom shaders sounds like an exiting plan as well... The "ultimate" plan would be to have an option for importing .fx files or something that we could mix with the realtime shadows of your viewer. Damn, I just want everything !:D
Honestly i think most of the features listed there people have other applications that handle, I could be wrong but i think it would be safe to say that atleast people using this in production will likely have some sort of app they can view animations, custom shaders, etc in a custom environment that their art is targeted towards anyway.
Yes, yes you are
A lot of contract artists, and budding artists alike, likely do not have access to any sort of model/animation viewer program. I don't work for a game studio anymore, so I don't have access to those sorts of tools. I use xNormal exclusively for viewing my models and shaders. But while it is very important for me to have that ability, there are many other things that xNormal can improve upon, before worrying about that.
That being said, I'm for the improved rendering & memory optimizations, as well as the GI renderer.
I agree with per, one of the nicest things about the program is it's small and has a purpose, i don't have to wade through hundreds of menus and features to do what i want....make a normal map.
Yep, exactly what Per and Tinman said ... don't add features just because one guy said "hey it would be cool if blah!", just make sure it is stable, fast and efficient.
all the stuff it does now is great. just needs a slightly more friendly and standard UI i think. Any speed or optimisation improvements would be cool too
Edit: and often the code gets cleaner and faster while working on a crossplatform version also.
I remember that John C. from id software once said that one of the biggest reason why they make a Linux port of all their engines is because while doing so it is possible to increase the quality of the windows port tremendously!
Edit: and often the code gets cleaner and faster while working on a crossplatform version also.
I remember that John C. from id software once said that one of the biggest reason why they make a Linux port of all their engines is because while doing so it is possible to increase the quality of the windows port tremendously!
although I am not an artist-user, I am with those who said the UI and the core are the most important things to focus on. as coder I know that other stuff is a lot of fun like the "viewer" with shaders and such, and makes development more entertaining for yourself. I'd suggest you do xEngine (well actually that one already exists hehe) or so whenver you feel the need for it, but dont pack every venture you feel you want to explore in one app. As Per said the less the better, as it will help bring stability and useability for its main purpose to a maximum. You can always link it with your "engine" later
judging from other feature requests many artists often have here, is that they want the super app, like an über-shader that has everything "perfect" + best shadows whatever... while the viewers sole purpose for xnormal should actually be to check if the baked normal is good, and for that actually the most standard way of presenting it, is the best, as its the one that presents the raw-data in a way that is not distorted by tons of other effects. Like you could have simple normalmaps with fixed function perpixel dot3 blending + vertexprogram and reach like 99% of the hardware out there that is capable of dot3, and have not so many compatbility issues (basically doom3's way). And some ARB vertex/fragment_programs and you get the 75 % of sm2+ hardware with a bit nicer effects. No buggy GLSL ati driver whatever, and I can assure you from experience made with luxinia, that the classic dot3 stuff works extremely robust
you do a lot of stuff, very well, and its brilliant that you do a 4.0 that is a complete "restart". a lean and mean app, simple but standard gui (maybe xml/lua customizeable for the hardcores), lots of commandline stuff for batching whatever. and it will be a instant winner. we are also investigating wxLua / wxWidgets combo as a possible embedded fronted for luxinia, and it looked like a good choice. Although portability was a bit more important for us, but it keeps downloadsize very small, and saves your from dependancy hell on .net / .dx stuff (though maybe you still need dx libs for some of the stuff you do internally ??)
Agreed with Per's long post about the accessibility of files, batching etc.
It always confused me that I couldn't manually type in a path name if I just wanted to rename the model from foo_01.obj to foo_02.obj ... that sort of thing would save a lot of time for users.
Naming conventions and options to set up prefixes/suffixes and numerical ranges for objects would be awesome IMHO.
[ QUOTE ]
[ QUOTE ]
A linux port would be extremely helpful
[/ QUOTE ]
what for?
Sorry I don't get it, this tool is for assisting artists on their daily routine, or do i get anything wrong? How many graphics tools are you using on linux? While this might be nice to have, it's defintely no must have, at least not to me, i agree with the posts before considering performance and handling, but a linux port is more for a marginal group.
Or do i just have prejudices, how many game artists are actually using Linux in their daily routine?
Please don't see this as a start for a flamewar, it's a serious question.
Yeah honestly what percentage of people using xnormal use linux? Is there some huge portion of polycount just waiting for xnormal to support linux so they they can all stop using windows?
I was thinking the exactly same thing Neox. Don't really think that worths it, at least not for production which should be the best bet on this application.
A thing that always made me use max render-to-texture instead of xNormal is the slow and not great quality AO render. I don't know if it is just with me, but it takes too much time really to render it, and afterall it dosen't look nearly as good as max's ones. That would complely buy me
I am using only graphic tools on Linux (there are quite a few, even Maya and XSI have Linux ports), but as I said it would be helpful (for me)
But there are not very many game artists using Linux, I agree.
That said the above mentioned reason still stands, and maybe a linux port with a command line interface would help rendering really complex normal-maps on a dedicated rendering system (which often use Linux)?
Command-line version. I'd like to be able to fire jobs off from my 3d app to be baked by it. Full command line mode would be extremely useful! (maybe take a parameter file instead of passing a really long command line, you'd probably hit limits).
[ QUOTE ]
Oh, another suggestion: Selective routing of the generated data. Which data goes into which channel should be up to me.
Maybe I want the output to be a file that contains the normal map in RGB and AO in alpha. Currently I have to open lots of different files with lots of data I don't need... and damn I'm tired of deleting totally unnecessary "_mask" files
[/ QUOTE ]
This is HUGE, im still using 3.10.5 just because there really hasnt been any performance improvements with ambocc as far as i can tell and rendering out all these extra maps and saving them as seperate files just eats up more and more of my time.
Also , why not make the viewer a separate exe ? could be cool and you could add all the prety effects you wanted and i dont think it would mess much with memory etc...i might be wrong tho/
Oh damn yeah, missed this earlier, but what Per said about being able to choose which files and channels to output maps into would be awesome - at the moment I have no control over it and end up deleting the "_mask" images and usually the AO bent normals stuff. That should all be optional and customiseable!
I haven't played with xnormal that much, but looked at the viewer and it didn't seem to let you add lights. The only reason I would use the viewer would be to check the maps and to show of the work, so an easy way to do that would be nice, even if you have to set up the scene in your 3d app of choice which I think would be better I think. So say the user set ups the scene, or scenes adds lighting, textures, animation and exports to your format and this format retains the information and when you load it up in the viewer it just works. I think if you are going to add these features to your app this might be a good way to do it. Great work though, I look foward to seeing your next update. If you are going to make your viewer stronger I think all it needs is
easy ways to place lights,
simple shader that supports, normal, diffuse, alpha, gloss maps, reflection, parallax and displays mirrored uvs easily.
While I'd LOVE a mac version, I'd much rather you spent the time just concentrating on a rock solid app. There must be other developers out there who could handle the port to other operating systems.
I've just installed it again at home, and there are some minor issues that you could easily iron out in 4.0 release.
The installer gives me far too many options with network rendering and plugins. Have two options - Standard and Custom, let people delve into the custom menu if they need to. scan the system for Photoshop/Max etc and just install those plugins.
When I go to run it from the start menu, it's under All Programs, Santiago Orgaz, xNormal, 3.12.0, xNormal. There no need for such a long path, why not just have an xNormal group?
And now the more obvious ease of use stuff:
Drag and Drop. Rather than browsing for everything, just drag and drop those project files into the right slots, instead of Right click, Browse mesh, Choose model type, find the file.
I must be missing something here. What's the first thing a person wants to do after they bake their normal maps, view them. Right now Xnormal is pretty close to a perfect app, it just needs some tweeks, I didn't go into the baking aspect of it because you guys covered it. I was thinking drag and drop would be great too. The other thing that might be nice would be a way to easily set in preferences what you bake all the time, so if for your project you need to bake ao, normal, spec, the app remembers these settings and that's it. Maybe you could make the app smart enough to know that if the user drag and drops the models onto the apps icon it will go and bake whatever the user set before hand and then it opens the viewer once everything is done. Having a toggle to turn on and off launching the viewer would be ideal though. When making models for ogre3d I used to drag and drop a selection of xml files onto the xml to mesh converter to save time for example. That said if a viewer is added it should be there to help bake maps and not be a just a tack on feature, like what photoshop cs 3 extended did with their 3d painting hack. In case of Xnormal being able to look at the model and find problem areas and lasso select that area and re render that section only would be nice.
[ QUOTE ]
Keg's viewer doesn't work properly though. The way it handles the normals is wonky.
[/ QUOTE ]
Tried the latest release Vassago? my viewer was using the normals stored with the obj file, i've changed it to calculate the normals when loading the obj.
Edit: sorry for the off topic. the focus here should be on xnormal.
I really dont understand why anyone would even complain about the current viewer if all they want to do is check if thier maps came out correctly, it works perfectly fine for that. You dont need to place 17 lights just to make sure you dont have any smoothing errors. Now what it seems like is that people want some sort of dedicated rendering solution built into xnormal, which really i dont think is worth the effort while the basis of the program can still be improved upon a lot.
Per I prefer xnormal to do what it does now which is an app that renders normal maps out of existing files and once the maps are created you can view the results. So I don't expect xnormal to be a 3d modeler or a sculpting program. As for the viewer it would be nice if it had a basic 3 point light setup. I just noticed the viewer pretty much has all the features I think it should have, except it's not as user friendly as I would like. The only thing that bugs me is that for some reason it doesn't let me exit the viewer because my mouse cursor never can reach the close button if I'm not in windowed mode, which is odd. It takes screenies and it has interesting controls, which isn't that nice but works fine. I can't see him having much of a problem adding a generic 3 light setup and if he made the viewport navigation be like Max Perspective or Silo 3d it would be awesome. Like I said the app is close to being perfect and it is very focused for normal map baking. It just needs a little automation and be more standard. I think the xnormal would be nicer if it had a simple ui like this that had the viewer and bake options together. So if Xnormal had a simple standard ui that 3d artists are used to using with nice navigation controls I think it would look something like this.
that would look a tad weird, having the polys drawn on screen would surely slow down thing. imo dont mix the viewer with the normal map tool, i want the normal map tool and amboc tool. period. mixing pretty stuff that will clutter it bettter be external.
I was thinking the baking would happen when the models where loaded. then it would show the result. It can't be any slower than Max or XSI, the texture would update after the bake was completed.
Thats the point though, it would slow it down to Max and XSI speeds. The whole reason I ended up using xnormal was because it could handle the model i was giving it. I didnt have to wait for millions of polies to be drawn on screen. I simply add my models to a list and let it do it's thing.
Wah, no, nothing at all like what Sage suggests in that screenshot! That'd be pretty bad IMHO.
I think just a resizeable window with tabs on the top for the menu fields that currently go down the right hand side, and as few options as possible, would be great.
i'm probably the only one, but if i have a combination model like a tree that has seperate maps/uvs for leaves and for the tree itself, i'd like to be able to see both in the viewer at the same time.
if it already does this, then i'll just stop breathing.
So what would you have the 3D window do? Auto-load the lowpoly, and then have toggles to load and display the highpoly, or load and display the maps?
That way you wouldn't have to wait for textures or geometry to load, the lowpoly files load pretty fast to display anyway.
I just think it seems a bit of a waste to have the majority of the screen being a viewer when most of your time will be spent changing options for baking, or adding/removing models from lists. I would personally give more screen space to having the model lists all showing up at once (instead of being crammed into columns down the right), and then have the option to switch to the viewer.
I just don't think one toolbar would be enough when you consider the many things you can choose and do in XNormal. I reckon it'd end up cluttered pretty fast.
Are you suggesting having each thing as a rollout? That might work. At the moment Sage's mockup doesn't cover even 1/10th of the things you need for XNormal.
I'll be more forgiving when someone makes a mockup which includes ALL of the things you will need to access.
In Sage's version, where do you choose highpoly files? Where do you choose lowpoly? How do you set the ray distances on those meshes, How do you run the GPU AO tool? Where do you assign textures to the lowpoly model? Or the high poly for that matter?
I can see all of that stuff fitting in rollouts, I guess. I'm just not sure that it would really suit that sort of layout, Silo doesn't deal with long file names and numerical settings per file, especially in the sidebar.
It seems to me that a lot of the information you would need (mesh names, ray distances etc) would be more suited to a horizontal layout than a vertical one.
I had a bit of time to think about what Johny mentioned, about speed, I was wondering what the hell he was talking about. I just got back. The UI thing is just a layout, I wouldn't have take up the entire window unless the user wanted it that way. For the display part yeah I get that the highpoly would slow things down, but I was thinking that when the models loaded only the low would be displayed, I can't see why the high would be needed, it would be nice if the baker could do it's thing without having to display both models. Tinman XSI on my machine redraws wireframes of high poly models, millions of polys, fine, much better than Max and I only have a gig of ram, but yeah, now I get why the viewer could cause problems. I must have had a senior moment, or blond moment there. The ui is screen grab of silo, I just Photoshoped it a bit. It's just to illustrate what I was thinking of "more standard" tool. Ideally there would be a menu that comes up with a right click. The side would just have options for baking, it be nice however if this could be grown like in max so if the user wants a small viewport it could happen and better yet just turn it of with a toggle. Again I came up with this in five minutes. But again I want both, what xnormal offers now just in a more standard and condensed manner. I think the baking is more important though, maybe I should have stated that, but whatever, I'm not here to be a cheerleader. It might help if you guys explain a little how you use xnormal in your workflow, I mean habits, not just the fluff so Joshgy can come up with a nicer app than he already has.
Just read your last post Mop. Well for one you can have short cut call up the menus. ASDFG kind of thing and what you want to see shows up, and takes up as much space as needed of the ui. I don't really think it's a huge problem especially if the information is put into the app in a more streamlined fashion.
i use it to everykind of map geneartion from 1024x1024 to 2048x2048 with models that are kinda heavy ( i dont render stuff in max anymore ), and i cant render it past 1x antialiasing with 3 gigs of ram and core duo since it gives me outta memory issues, also the amboc tool in the last is fudged, so in my opinion the program shoul focus on increasing the speed and reducing memory usage and i would be a happy man, you guys can throw all kinds of things on it as long as it wouldnt consume more memory.
looks cool, but i dont think that having the viewer implemented is much practical ( unless it was only the lowpoly ) since we already saw them on the 3d program :S , i honestly still think that Xnormal should be an amboc and xnormal generator, all that extra jazz could be implemented after he has a stable memory management program .
this thread is getting me pumped up for the next xnormal .
I'm fine with how the viewer is right now. I don't need to import my own shaders and all of that crap. I also don't think it's necessary to have the viewer visible at all times like that. But it sounds like some of you are asking to remove the viewer altogether? That's completely boneheaded if you ask me.
Work on what's most important, speed and convenience of baking maps. Period. Keep the viewer, don't worry about improving it for now, as it's damn good as is.
In the UI, do you need separate sections for Low and high poly?
How about something with a little more abstraction? An asset is an asset, and can be flagged as low or high poly after import. Drag a bunch of model assets into an asset manager, then link them up afterwards. This can be done via dialogues (yuck) or sexy nodes. Imagine not only dragging a texture into a text box, but dragging it onto a model asset.
Per: The problem with your method (and I can see all the things that are good about it, I know where you're coming from!) is that it seems very specific to the workflow you're using.
For example, if you've got your "soldier_maleA_head" which is the all-encompassing prefix to your assets (_high, _low, _normal, _diffuse, whatever), that only really works if you have a single highpoly object containing all of the relevant subobjects. As soon as you start assembling a mesh to be baked with several different highpoly files, it no longer works (unless I'm missing something?)
While I understand the benefits of having a setup like you described on the last page, I don't think it's reasonable to assume that everyone else will want to (or even be able to) work the same way, and being able to support those different methods of working would just add more bloat and confusion to the mesh selection stages.
Maybe some sort of checkbox in the options could enable that (like "use same name for meshes and maps" or something), so then you just select your highpoly and it automatically looks for the other files based on suffixes you specify in the same options menu. Dunno how much work that would be for Santiago though.
I think it definitely makes sense to be able to toggle "sub-object" visibility and options for meshes inside a file. I'm gonna mess around a bit more with this mockup and make it more friendly for that, completely forgot when I was setting up it up earlier
Oh, naming conventions are great, but the application author shouldn't force naming conventions upon it's users. Be more fluffy. xNormal 4.fluff.
Dropping a bunch of objects into a package and having it figure it all out is still a pain - I've written maxscripts to do that and it's messy, and that's even with artists usually naming stuff correctly.
[ QUOTE ]
Although it's the only professional thing to do, graphics artists are morons and can't be counted on!
Mop I think that UI is really good, just without the viewer constantly open. I was just thinking of having a view model button so you can still use the viewer if you want .
Yeah, initially I was thinking the viewer wouldn't be worth having up, but the more I think about it, the more I like the idea - by default it would only display the lowpoly meshes with gouraud shading and all the vertex normals (just so you can make sure your export came in correctly with regard to smoothing groups etc.)
Rick: Absolutely, that's why I kind of like the current XNormal setup, it caters to pretty much everyone, and with a bit of streamlining it could probably even do what Per is saying
I don't think it'd take long to read in a lowpoly model, although I would definitely say turn it off if loading and displaying a lowpoly model would slow down the map baking process much.
I guess if the feature was implemented, it could also switch to a "preview" window so you can see the progress of normals rendering (although this would be toggled in the options with a warning that it will slow down baking).
Very nice layout Mop, I was thinking xnormal needed an easy photoshop layer system. As far as loading things in what's so hard about dragging and dropping the low poly model and xnormal looking for the hi res itself, or the user selecting everything and dropping in at once. Smart users use naming conventions cause it saves time. So say the only thing the user is required to do save the file as whatever_low or whatever_high, xnormal uses a wild card system to find the files. so if the user decided it was too much work to write whatever_low and do a whatever_l instead xnormal would be able to find it and it's high poly. I was also thinking that xnormal native format could support layers for example so when the user exports the scene from their 3d package it keeps the layers and loads everything intact, the models and that eliminates the need for the user to save out separate chuncks to a degree, although this might not really matter since a lot of times you save out separate chuncks anyway. Just an idea though.
Latest version:
(disclaimer, the "visibility" icon is ripped right from Silo, I'm too lazy to do my own yet!)
<u>Overview</u>
- My main changes here are shuffling around all the existing tools and settings into a more standard Windows interface.
- All of the "most-used" features are in collapsible headings on the right-hand taskbar.
- All of the less important options are moved into the top menus.
- A standard "status bar" at the bottom with Rendering Progress bar, RAM Usage bar, and "status indicator" flashing light.
- Generate Maps button stays visible at the bottom of the right-hand task bar.
- Sound effects and animations removed completely.
- Any text fields are drag-droppable, just pull a model file into the correct heading and it would add the model, same with textures.
- Viewer present at all times. By default, only loads the lowpoly mesh and shows it in gouraud shading with vertex normals, to check that your model is loading correctly. Also can display normals/AO on model once baking is complete.
<u>More info / random stuff</u>
Yes, people have said "why have the viewer up since I've just been looking at my model in Max or Maya or whatever", but it's probably a decent precaution just to be sure you haven't made any weird screw-ups with exporting the wrong meshes or having incorrect export options leading to bad normals or flipped faces, etc.
Better to see it there in a quick loaded mesh, than after you've spent 20 minutes baking normals only to realise you forgot to Freeze Transformations or Reset XForm before export or whatever.
In the highpoly rollout, any meshes detected with "sub-objects" would be able to be expanded to toggle visibility of the sub-objects. XNormal would automatically assign random colours to each individual object ID, but the swatches could be changed per object if you wanted to bake a simple diffuse base (for painting on, or for masking selection areas etc.).
It would be worth doing a "sanity check" on sub-objects which are numbered in clone fashion (ie rivet01, rivet02... rivet64 etc.) and condense those down to a single "sub-object" called "rivet". Otherwise with complex highpoly meshes you might end up with an un-manageable number of sub-objects.
Or you could maybe have a checkbox for "treat as single object" if you didn't want to work with sub-objects.
Note that the "browse" icon is only visible for meshes already loaded. The empty fields below, you would double-click on to bring up the file browser, single-click on to type a path, or drag and drop from outside the program. You would also be able to edit any of the existing paths by hand (eg. changing mesh_head1.obj to mesh_head2.sbm or whatever).
3D viewer clutter would be kept to a minimum on the screen, all of those other options like light colour and brightness and various shader effects, would be in the rollout on the right (shown minimised in my mockup). Only the main and most obvious options would stay in the viewport, and I added crappy icons for Zoom Extents and Light To Camera Position.
I still need to revise the baking normals section. I like the idea of being able to choose how to output textures (ie. put the ambiocc in the alpha channel of the local map if you want), but I'm not sure how to represent that sort of behaviour at the moment.
Stuff in the current XNormal version like the Support and About section, and the Settings and Examples section, would become part of the menus at the top. So instead of going into Settings and Examples to load an example, you'd do File -> Open, and File -> Save to save settings, just to feel a bit more comfortable and standardised.
Similarly all the info found in Support and About would be moved to the Help menu, as shown.
The Plugin Manager is moved from the bottom left into an actual menu where it's more obvious. It would open a standard Windows option tab window.
Long-winded but hopefully useful... any feedback or better solutions welcome! I don't even know if Santiago wants to do something like this, but I certainly know I'd like using this interface a lot better than the current one
Replies
I think that a more standard windows style UI would be great, it feels kinda weird and unnecessary the way the whole app is set up at the moment.
I think it'd be nicer just to put the current pages into a standard windows tab arrangement.
It might be nice to have a more standard UI, i dont even really see the need to make it customizable, just having a more standard look. That being said i'm used to the UI and wouldnt complain if you spent all of your time just making speed/memory improvements and did nothing else on the list here.
I could be wrong
[/ QUOTE ]
Yes, yes you are
A lot of contract artists, and budding artists alike, likely do not have access to any sort of model/animation viewer program. I don't work for a game studio anymore, so I don't have access to those sorts of tools. I use xNormal exclusively for viewing my models and shaders. But while it is very important for me to have that ability, there are many other things that xNormal can improve upon, before worrying about that.
That being said, I'm for the improved rendering & memory optimizations, as well as the GI renderer.
all the stuff it does now is great. just needs a slightly more friendly and standard UI i think. Any speed or optimisation improvements would be cool too
Edit: and often the code gets cleaner and faster while working on a crossplatform version also.
I remember that John C. from id software once said that one of the biggest reason why they make a Linux port of all their engines is because while doing so it is possible to increase the quality of the windows port tremendously!
A linux port would be extremely helpful
Edit: and often the code gets cleaner and faster while working on a crossplatform version also.
I remember that John C. from id software once said that one of the biggest reason why they make a Linux port of all their engines is because while doing so it is possible to increase the quality of the windows port tremendously!
[/ QUOTE ]
seconded
right now, there's virtually nothing on linux
judging from other feature requests many artists often have here, is that they want the super app, like an über-shader that has everything "perfect" + best shadows whatever... while the viewers sole purpose for xnormal should actually be to check if the baked normal is good, and for that actually the most standard way of presenting it, is the best, as its the one that presents the raw-data in a way that is not distorted by tons of other effects. Like you could have simple normalmaps with fixed function perpixel dot3 blending + vertexprogram and reach like 99% of the hardware out there that is capable of dot3, and have not so many compatbility issues (basically doom3's way). And some ARB vertex/fragment_programs and you get the 75 % of sm2+ hardware with a bit nicer effects. No buggy GLSL ati driver whatever, and I can assure you from experience made with luxinia, that the classic dot3 stuff works extremely robust
you do a lot of stuff, very well, and its brilliant that you do a 4.0 that is a complete "restart". a lean and mean app, simple but standard gui (maybe xml/lua customizeable for the hardcores), lots of commandline stuff for batching whatever. and it will be a instant winner. we are also investigating wxLua / wxWidgets combo as a possible embedded fronted for luxinia, and it looked like a good choice. Although portability was a bit more important for us, but it keeps downloadsize very small, and saves your from dependancy hell on .net / .dx stuff (though maybe you still need dx libs for some of the stuff you do internally ??)
It always confused me that I couldn't manually type in a path name if I just wanted to rename the model from foo_01.obj to foo_02.obj ... that sort of thing would save a lot of time for users.
Naming conventions and options to set up prefixes/suffixes and numerical ranges for objects would be awesome IMHO.
[ QUOTE ]
A linux port would be extremely helpful
[/ QUOTE ]
what for?
Sorry I don't get it, this tool is for assisting artists on their daily routine, or do i get anything wrong? How many graphics tools are you using on linux? While this might be nice to have, it's defintely no must have, at least not to me, i agree with the posts before considering performance and handling, but a linux port is more for a marginal group.
Or do i just have prejudices, how many game artists are actually using Linux in their daily routine?
Please don't see this as a start for a flamewar, it's a serious question.
A thing that always made me use max render-to-texture instead of xNormal is the slow and not great quality AO render. I don't know if it is just with me, but it takes too much time really to render it, and afterall it dosen't look nearly as good as max's ones. That would complely buy me
But there are not very many game artists using Linux, I agree.
That said the above mentioned reason still stands, and maybe a linux port with a command line interface would help rendering really complex normal-maps on a dedicated rendering system (which often use Linux)?
Oh, another suggestion: Selective routing of the generated data. Which data goes into which channel should be up to me.
Maybe I want the output to be a file that contains the normal map in RGB and AO in alpha. Currently I have to open lots of different files with lots of data I don't need... and damn I'm tired of deleting totally unnecessary "_mask" files
[/ QUOTE ]
This is HUGE, im still using 3.10.5 just because there really hasnt been any performance improvements with ambocc as far as i can tell and rendering out all these extra maps and saving them as seperate files just eats up more and more of my time.
easy ways to place lights,
simple shader that supports, normal, diffuse, alpha, gloss maps, reflection, parallax and displays mirrored uvs easily.
Alex
The installer gives me far too many options with network rendering and plugins. Have two options - Standard and Custom, let people delve into the custom menu if they need to. scan the system for Photoshop/Max etc and just install those plugins.
When I go to run it from the start menu, it's under All Programs, Santiago Orgaz, xNormal, 3.12.0, xNormal. There no need for such a long path, why not just have an xNormal group?
And now the more obvious ease of use stuff:
Drag and Drop. Rather than browsing for everything, just drag and drop those project files into the right slots, instead of Right click, Browse mesh, Choose model type, find the file.
Alex
Keg's viewer doesn't work properly though. The way it handles the normals is wonky.
[/ QUOTE ]
Tried the latest release Vassago? my viewer was using the normals stored with the obj file, i've changed it to calculate the normals when loading the obj.
Edit: sorry for the off topic. the focus here should be on xnormal.
Alex
Alex
I think just a resizeable window with tabs on the top for the menu fields that currently go down the right hand side, and as few options as possible, would be great.
I'll mock one up when I get home.
if it already does this, then i'll just stop breathing.
That way you wouldn't have to wait for textures or geometry to load, the lowpoly files load pretty fast to display anyway.
I just think it seems a bit of a waste to have the majority of the screen being a viewer when most of your time will be spent changing options for baking, or adding/removing models from lists. I would personally give more screen space to having the model lists all showing up at once (instead of being crammed into columns down the right), and then have the option to switch to the viewer.
I just don't think one toolbar would be enough when you consider the many things you can choose and do in XNormal. I reckon it'd end up cluttered pretty fast.
Are you suggesting having each thing as a rollout? That might work. At the moment Sage's mockup doesn't cover even 1/10th of the things you need for XNormal.
I'll be more forgiving when someone makes a mockup which includes ALL of the things you will need to access.
In Sage's version, where do you choose highpoly files? Where do you choose lowpoly? How do you set the ray distances on those meshes, How do you run the GPU AO tool? Where do you assign textures to the lowpoly model? Or the high poly for that matter?
I can see all of that stuff fitting in rollouts, I guess. I'm just not sure that it would really suit that sort of layout, Silo doesn't deal with long file names and numerical settings per file, especially in the sidebar.
It seems to me that a lot of the information you would need (mesh names, ray distances etc) would be more suited to a horizontal layout than a vertical one.
Just read your last post Mop. Well for one you can have short cut call up the menus. ASDFG kind of thing and what you want to see shows up, and takes up as much space as needed of the ui. I don't really think it's a huge problem especially if the information is put into the app in a more streamlined fashion.
Alex
this thread is getting me pumped up for the next xnormal .
Mop , that ui is also fantastic btw.
Work on what's most important, speed and convenience of baking maps. Period. Keep the viewer, don't worry about improving it for now, as it's damn good as is.
How about something with a little more abstraction? An asset is an asset, and can be flagged as low or high poly after import. Drag a bunch of model assets into an asset manager, then link them up afterwards. This can be done via dialogues (yuck) or sexy nodes. Imagine not only dragging a texture into a text box, but dragging it onto a model asset.
For example, if you've got your "soldier_maleA_head" which is the all-encompassing prefix to your assets (_high, _low, _normal, _diffuse, whatever), that only really works if you have a single highpoly object containing all of the relevant subobjects. As soon as you start assembling a mesh to be baked with several different highpoly files, it no longer works (unless I'm missing something?)
While I understand the benefits of having a setup like you described on the last page, I don't think it's reasonable to assume that everyone else will want to (or even be able to) work the same way, and being able to support those different methods of working would just add more bloat and confusion to the mesh selection stages.
Maybe some sort of checkbox in the options could enable that (like "use same name for meshes and maps" or something), so then you just select your highpoly and it automatically looks for the other files based on suffixes you specify in the same options menu. Dunno how much work that would be for Santiago though.
I think it definitely makes sense to be able to toggle "sub-object" visibility and options for meshes inside a file. I'm gonna mess around a bit more with this mockup and make it more friendly for that, completely forgot when I was setting up it up earlier
Dropping a bunch of objects into a package and having it figure it all out is still a pain - I've written maxscripts to do that and it's messy, and that's even with artists usually naming stuff correctly.
[ QUOTE ]
Although it's the only professional thing to do, graphics artists are morons and can't be counted on!
[/ QUOTE ]
Rick: Absolutely, that's why I kind of like the current XNormal setup, it caters to pretty much everyone, and with a bit of streamlining it could probably even do what Per is saying
I don't think it'd take long to read in a lowpoly model, although I would definitely say turn it off if loading and displaying a lowpoly model would slow down the map baking process much.
I guess if the feature was implemented, it could also switch to a "preview" window so you can see the progress of normals rendering (although this would be toggled in the options with a warning that it will slow down baking).
I think I've scared Santy off
Alex
(disclaimer, the "visibility" icon is ripped right from Silo, I'm too lazy to do my own yet!)
<u>Overview</u>
- My main changes here are shuffling around all the existing tools and settings into a more standard Windows interface.
- All of the "most-used" features are in collapsible headings on the right-hand taskbar.
- All of the less important options are moved into the top menus.
- A standard "status bar" at the bottom with Rendering Progress bar, RAM Usage bar, and "status indicator" flashing light.
- Generate Maps button stays visible at the bottom of the right-hand task bar.
- Sound effects and animations removed completely.
- Any text fields are drag-droppable, just pull a model file into the correct heading and it would add the model, same with textures.
- Viewer present at all times. By default, only loads the lowpoly mesh and shows it in gouraud shading with vertex normals, to check that your model is loading correctly. Also can display normals/AO on model once baking is complete.
<u>More info / random stuff</u>
Yes, people have said "why have the viewer up since I've just been looking at my model in Max or Maya or whatever", but it's probably a decent precaution just to be sure you haven't made any weird screw-ups with exporting the wrong meshes or having incorrect export options leading to bad normals or flipped faces, etc.
Better to see it there in a quick loaded mesh, than after you've spent 20 minutes baking normals only to realise you forgot to Freeze Transformations or Reset XForm before export or whatever.
In the highpoly rollout, any meshes detected with "sub-objects" would be able to be expanded to toggle visibility of the sub-objects. XNormal would automatically assign random colours to each individual object ID, but the swatches could be changed per object if you wanted to bake a simple diffuse base (for painting on, or for masking selection areas etc.).
It would be worth doing a "sanity check" on sub-objects which are numbered in clone fashion (ie rivet01, rivet02... rivet64 etc.) and condense those down to a single "sub-object" called "rivet". Otherwise with complex highpoly meshes you might end up with an un-manageable number of sub-objects.
Or you could maybe have a checkbox for "treat as single object" if you didn't want to work with sub-objects.
Note that the "browse" icon is only visible for meshes already loaded. The empty fields below, you would double-click on to bring up the file browser, single-click on to type a path, or drag and drop from outside the program. You would also be able to edit any of the existing paths by hand (eg. changing mesh_head1.obj to mesh_head2.sbm or whatever).
3D viewer clutter would be kept to a minimum on the screen, all of those other options like light colour and brightness and various shader effects, would be in the rollout on the right (shown minimised in my mockup). Only the main and most obvious options would stay in the viewport, and I added crappy icons for Zoom Extents and Light To Camera Position.
I still need to revise the baking normals section. I like the idea of being able to choose how to output textures (ie. put the ambiocc in the alpha channel of the local map if you want), but I'm not sure how to represent that sort of behaviour at the moment.
Stuff in the current XNormal version like the Support and About section, and the Settings and Examples section, would become part of the menus at the top. So instead of going into Settings and Examples to load an example, you'd do File -> Open, and File -> Save to save settings, just to feel a bit more comfortable and standardised.
Similarly all the info found in Support and About would be moved to the Help menu, as shown.
The Plugin Manager is moved from the bottom left into an actual menu where it's more obvious. It would open a standard Windows option tab window.
Long-winded but hopefully useful... any feedback or better solutions welcome! I don't even know if Santiago wants to do something like this, but I certainly know I'd like using this interface a lot better than the current one
Cheers!