[Bf-gamedev] BGE to visual Presentation and Blender for easier usage for other gamengines.

Matt Three ragingelbows at gmail.com
Fri Sep 27 02:26:51 CEST 2013


Sorry to spam everyone, but there was already some work done on normals
editing...thought it might be useful to let people know: It seems like the
left hand does not know what the right hand is doing in Blender development
sometimes.  Perhaps someone could ask Felix for his code.

http://blenderartists.org/forum/showthread.php?284736-Normals-Editing-in-Blender


On Thu, Sep 26, 2013 at 4:49 PM, Jason Wilkins <jason.a.wilkins at gmail.com>wrote:

> Thanks Matt.  I have quite enough to do regarding Blender, but I'll take a
> good look at what you've linked me.
>
>
> On Thu, Sep 26, 2013 at 6:30 PM, Matt Three <ragingelbows at gmail.com>wrote:
>
>> As a followup and clarification, here is an example of how editing vertex
>> normals works in Maya:
>>
>> http://www.youtube.com/watch?v=APV11HL6_es
>>
>> There was a script awhile back that could transfer normals like you see
>> in the Maya video, but there was no way to edit individual normals, and any
>> transfer needed to be done in object mode:
>> http://www.youtube.com/watch?v=FrxWAo5isB0
>>
>> Basically, any transfer done is destroyed the minute edit mode is
>> entered.
>>
>> I think a good way to implement this in Blender is to essentially copy
>> how Maya does it:
>>
>>
>> http://download.autodesk.com/global/docs/maya2014/en_us/index.html?url=files/Editing_polygons_Edit_the_vertex_normals_to_affect_polygon_shading.htm,topicNumber=d30e163432
>>
>> To implement this in Blender first you would need to stop the automatic
>> recalculation of vetex normals, and then allow them to be edited.
>>
>> Basically, a user would be able to turn vertex normals on in the display
>> tab of the properties panel (n key) select a vertex, and use the rotation
>> tool to edit the vertex normal direction.
>>
>> I assume stopping their recalculation is a pretty big task (or it could
>> be trivial) but that would be the first step, as there is no point in being
>> able to edit vertex normals if there is no way to keep them.
>>
>> Hope that helps.
>>
>>
>> On Thu, Sep 26, 2013 at 4:17 PM, Matt Three <ragingelbows at gmail.com>wrote:
>>
>>>
>>> https://docs.google.com/spreadsheet/ccc?key=0AuS_F0ZKX-zTdGxKOEMtRmI2Tno4UUlPZzVfNXB6RHc#gid=0
>>>
>>> is pretty much the canonical document for what is missing. For a modern
>>> workflow the big ones are:
>>>
>>> Editable vertex normals with proper export support for smoothing groups.
>>>  This is partially implemented in the new FBX/.obj exporters, however, as
>>> edit mode recalculates vertex normals every time you enter it, it's a huge
>>> problem.
>>>
>>> http://wiki.polycount.net/VertexNormal?action=AttachFile&do=get&target=TreeMakerScript_plus_NormalThiefScript.gif is
>>> an example of why we need editable vertex normals.  For low poly objects it
>>> is extremely important to be able to control shading, and a primary way to
>>> do this is through editing normals and setting hard/soft edges.  Not to
>>> mention that without proper normals your bakes will not work right.
>>>
>>> Cage baking and baking with AA (normally we get around this with
>>> X-normal).  Proper support for cage baking would mean that we wouldn't need
>>> to use a third party app to get proper bakes that work in game engines.
>>>
>>> I think these are the two big ones.  Support for edited normals is
>>> important for getting data out of Blender that game engines understand.
>>> Right now there are some work arounds but it is really difficult to do
>>> certain things, such as foliage, without edited vertex normals.  Cage
>>> baking is what would be needed to make Blender a one stop app for creating
>>> game assets.  Right now we're almost required to use Xnormal and Handplane
>>> to get our meshes looking right in engines like UDK.
>>>
>>> I'm sure other artists (Andy Davies, feel free to chime in here) would
>>> need other features, but those two seem to be the common consensus as far
>>> as basic feature completeness.
>>>
>>> I would add the ability to bake global illumination (i.e. Cycles baking)
>>>  and the ability to bake displacement maps as two other features that are
>>> notably absent in blender.  However, they aren't show stoppers like the
>>> vertex normal and baking support are.
>>>
>>>
>>>
>>> On Thu, Sep 26, 2013 at 4:02 PM, Jason Wilkins <
>>> jason.a.wilkins at gmail.com> wrote:
>>>
>>>> To begin to address missing features, is there a list of things that
>>>> are missing that somebody could look at and start getting ideas of where to
>>>> begin?  If not one could start by creating concrete list of things Blender
>>>> can't do (or can't do easily) that missing and what one thinks would be
>>>> needed to make Blender "feature complete".
>>>>
>>>> My area is computer graphics and programming language research, so I
>>>> need to be pointed in the right direction ;-)
>>>>
>>>>
>>>> On Thu, Sep 26, 2013 at 5:17 PM, Matt Three <ragingelbows at gmail.com>wrote:
>>>>
>>>>> I honestly wouldn't worry about another language at the moment...I'm
>>>>> not sure what it would really add for game art creation.  I think a lot of
>>>>> tech artists are proficient in Python as it is used in Maya and Max
>>>>> scripting.  The big issue for most of us who use Blender for game projects
>>>>> on 3rd party engines is the missing features. Right now Blender is feature
>>>>> incomplete for game art creation when stacked up against Maya or 3ds Max.
>>>>> In my opinion this is the first thing that this list and effort should
>>>>> address.
>>>>>
>>>>>
>>>>> On Thu, Sep 26, 2013 at 2:01 PM, Jason Wilkins <
>>>>> jason.a.wilkins at gmail.com> wrote:
>>>>>
>>>>>> I'll admit adding Lua or other language support to Blender is
>>>>>> hypothetical, but I was thinking this list would be a good place gauge
>>>>>> interest.  It actually made me much more interested in adding Mono support
>>>>>> since I think having a strongly typed language would be much more
>>>>>> appreciated than adding yet another scripting language.
>>>>>>
>>>>>> Of course there will be a lot of "bike shedding" when the topic of
>>>>>> programming languages is raised, but I have a nice threaded mail reader so
>>>>>> it doesn't matter if the number next to the thread is [2] or [40], it isn't
>>>>>> "drowning out" anything.  I'll try to keep in mind that other people might
>>>>>> get more annoyed by the size of these numbers than me ;-)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 26, 2013 at 3:18 PM, Jacob Merrill <
>>>>>> blueprintrandom1 at gmail.com> wrote:
>>>>>>
>>>>>>> Ok, thank you sir...
>>>>>>> On Sep 26, 2013 1:09 PM, "Brecht Van Lommel" <
>>>>>>> brechtvanlommel at pandora.be> wrote:
>>>>>>>
>>>>>>>> If developers of the Blender game engine want to communicate with
>>>>>>>> users over this list I don't have a problem with that. This is a new
>>>>>>>> mailing list and we still have to see how it works out.
>>>>>>>>
>>>>>>>> But if we get long discussions about hypothetical projects that
>>>>>>>> drown
>>>>>>>> out the discussions on actual development work that is being done,
>>>>>>>> then people who can provide good feedback will ignore the list or
>>>>>>>> unsubscribe. And I think we are in danger of that happening, so I
>>>>>>>> just
>>>>>>>> want to remind people to try to avoid it.
>>>>>>>>
>>>>>>>> On Thu, Sep 26, 2013 at 9:00 PM, Jacob Merrill
>>>>>>>> <blueprintrandom1 at gmail.com> wrote:
>>>>>>>> > Ok,
>>>>>>>> >
>>>>>>>> > Very professional,
>>>>>>>> >
>>>>>>>> > BF-GameDev-
>>>>>>>> >
>>>>>>>> > I guess I thought it was about game development,
>>>>>>>> > Sorry....
>>>>>>>> >
>>>>>>>> > I guess I should maybe think about moving to another engine....
>>>>>>>> >
>>>>>>>> > what of the unpaid devs?
>>>>>>>> > Kupoman -etc?
>>>>>>>> >
>>>>>>>> > is there a list that I should be posting to about game
>>>>>>>> development?
>>>>>>>> >
>>>>>>>> > Android ports?
>>>>>>>> >
>>>>>>>> > _______________________________________________
>>>>>>>> > Bf-gamedev mailing list
>>>>>>>> > Bf-gamedev at blender.org
>>>>>>>> > http://lists.blender.org/mailman/listinfo/bf-gamedev
>>>>>>>> >
>>>>>>>> _______________________________________________
>>>>>>>> Bf-gamedev mailing list
>>>>>>>> Bf-gamedev at blender.org
>>>>>>>> http://lists.blender.org/mailman/listinfo/bf-gamedev
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Bf-gamedev mailing list
>>>>>>> Bf-gamedev at blender.org
>>>>>>> http://lists.blender.org/mailman/listinfo/bf-gamedev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Bf-gamedev mailing list
>>>>>> Bf-gamedev at blender.org
>>>>>> http://lists.blender.org/mailman/listinfo/bf-gamedev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Bf-gamedev mailing list
>>>>> Bf-gamedev at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-gamedev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Bf-gamedev mailing list
>>>> Bf-gamedev at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-gamedev
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Bf-gamedev mailing list
>> Bf-gamedev at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-gamedev
>>
>>
>
> _______________________________________________
> Bf-gamedev mailing list
> Bf-gamedev at blender.org
> http://lists.blender.org/mailman/listinfo/bf-gamedev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-gamedev/attachments/20130926/5b7cdc30/attachment.htm 


More information about the Bf-gamedev mailing list